Prevent the default logger from flooding console in `cargo test`

[SpriteOvO]

Discussed in #104

^{Originally posted by @JensMertelmeyer October 24, 2025}
We use spdlog heavily throughout our application. However, running cargo test will flood the console with logs because in several hundred tests, we were too lazy to set up a separate mock logging instance and it will all go to spdlog's default stdout/stderr logger.

I have not been able to find a way around it. While spdlog's creation of a default logger (if none has been set up yet) is a beautiful feature, it's not quite what we need within our tests.

Would it be possible to put this behind a feature flag? Or is there some other way of controlling (possibly from Cargo.toml what the default logger should be (like chosing between a "null" logger or regular stdout/stderr)?

[SpriteOvO]

The std {,e}print{,ln}! macros can hide the outputs for cargo test is because they have an internal "capture" mechanism, and unfortunately these stuff are not public at all.

https://github.com/rust-lang/rust/blob/ab925646fae038b02bd462cd328ae9eef1639236/library/std/src/io/stdio.rs#L1169-L1180

spdlog-rs default logger configures StdStreamSink by default, which writes to std::io::{stdout,stderr}() directly without going through that "capture".

---

Just got an instant thought about how we can replicate the behavior in spdlog-rs.

• Since #[cfg(test)] will not propagated to dependencies, a new feature gate for spdlog-rs is probably required, and then downstream crates need to add spdlog-rs to the section [dev-dependencies] in Cargo.toml for enabling the behavior for cargo test, like this:

[dev-dependencies]
spdlog-rs = { version = "x.y.z", features = ["new-feature-name-tbd"] }

• Solution 1: When the new feature is enabled, we call std::env::args() in StdStreamSink to check if --show-output and --nocapture is specified, if not, we skip all writes in StdStreamSink.

• Solution 2: When the new feature is enabled, we replace all std::io::{stdout,stderr}().write with {,e}print!()! macros, this makes us to write buffer through the stdlib internal "capture" mechanism. But these macros will always panic if any write fails, instead of returning an error like the former. See PR Replace eprintln! with writeln! to avoid broken stdio panic #88 for the similar situation, but this should be quite rare in cargo test.

About the new feature name, maybe "test"?

CC @Lancern @tisonkun for any thoughts on this?

[Lancern]

When the new feature is enabled, maybe we could make StdStreamSink write directly through (e)print! macros?

About the new feature name, maybe "test"?

LGTM.

[tisonkun]

In Logforth, the practice is like solution 2 - fast/logforth#139

I think in a testing environment, people would be fine that eprintln! panics when it is.

[SpriteOvO]

When the new feature is enabled, maybe we could make StdStreamSink write directly through (e)print! macros?

@Lancern This is exactly what I meant in solution 2 :)

I have opened a PR #106 to implement solution 2 just now.