test-log
test-log copied to clipboard
d-e-s-o
A replacement of the #[test] attribute that initializes logging and/or tracing infrastructure before running tests.
If I run this test it starts 2 times ``` #[tokio::test] #[test_log::test] async fn test1() { println!("test1"); } ``` ``` ❯ /usr/bin/cargo test --color=always --package rencfs --lib mycrate::test::test1 --no-fail-fast --...
This PR is based on #48. Only the last commit belongs to this PR. --- This adds support for [tracing-flame](https://github.com/tokio-rs/tracing/tree/master/tracing-flame). (See #47) This PR works, but might need some work...
First of all, this crate is awesome! One thing I am missing is the ability to use [tracing-flame](https://github.com/tokio-rs/tracing/tree/master/tracing-flame). I think having this as an option for tests might be helpful....
This way if preceding test macros add `#[::core::prelude::v1::test]` by appending, then we can avoid duplicated test runs. See also frondeus/test-case#101, frondeus/test-case#143 Closes #35. This pr depends on frondeus/test-case#143 and tokio-rs/tokio#6497.
# Issue Make `default_log_filter` stable by implementing a parallel-friendly way to manage environment variables. # Proposed Solution The [commit](https://github.com/d-e-s-o/test-log/commit/cbcdb8ca83cf4786896b6083bf2ef38ec9304891) putting the `default_log_filter` attribute behind the "unstable" feature is awesome, but...
Spin-off from #30. It is not possible to write `#[test_case(...)]` tests with multiple cases. For example ```rust #[test_log::test(test_case::test_case(-2, -4; "one"))] #[test_log::test(test_case::test_case(-4, -2; "two"))] fn it_works(x: i8, y: i8) { //...
This crate is a good idea. We have in our current tests a custom log format to log e.g. the line of code and the time. We do this to...
I'm writing a library that needs to be tested *inside `no_std` environments*. Since `tracing`, and `tracing-subscriber` do not inherently require `std`, it would be convenient to be able to use...
