A Rust crate that automatically initializes logging and tracing infrastructure for tests via a custom #[test] attribute.
test-log is a Rust crate that automatically initializes logging and tracing infrastructure before running tests, eliminating the need for repetitive setup code in each test. It provides a custom #[test] attribute that handles initialization for the `log` and/or `tracing` crates, making verbose debug output readily accessible during test execution.
Rust developers writing tests for codebases that use the `log` or `tracing` crates for logging, particularly those who need to debug tests by viewing log messages.
Developers choose test-log because it removes the boilerplate of manually initializing logging in every test, supports both `log` and `tracing` backends with flexible configuration, and integrates seamlessly with other test attributes like `#[tokio::test]` for async testing.
A replacement of the #[test] attribute that initializes logging and/or tracing infrastructure before running tests.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Provides a custom #[test] attribute that automatically initializes log and tracing backends, removing the need for repetitive code like env_logger::try_init() in every test, as highlighted in the README.
Supports both log and tracing crates via Cargo features, allowing developers to enable only the backends they use, with configurable options like trace and color features.
Can be stacked with attributes like #[tokio::test] for seamless logging in async tests, demonstrated in the README with examples of attribute stacking.
Honors standard variables like RUST_LOG and RUST_LOG_SPAN_EVENTS for easy log-level and span event control without code changes, leveraging env_logger and tracing-subscriber.
Stacking with other #[test] attributes requires cooperation from those crates, and a less intuitive wrapping syntax may be needed as a fallback, as noted in the README regarding compatibility issues.
Initialization is tied to specific setups like env_logger for log; for advanced or custom logging configurations, users may need to bypass the crate's defaults, which isn't supported out of the box.
With separate features for log and tracing, incorrect configuration in Cargo.toml can lead to missing log output, adding complexity and potential confusion for developers.