dbrgn / tracing-test

Access and evaluate tracing logs in async and sync tests.
Apache License 2.0
52 stars 26 forks source link

Update macro to allow overriding the target at compile time #26

Closed inferiorhumanorgans closed 4 months ago

inferiorhumanorgans commented 1 year ago

Currently I'm using frondeus/test-case to parameterize some of my tests. Unfortunately it ends up creating a "super" test by concatenating the names of all of your variants (or worse the parameters). This isn't a huge problem until you want to look at the logs (e.g. with tracing-test) and all of a sudden your tracing target is well over a hundred characters (and not meaningful even if it were shorter).

The implementation feels a bit gross, but the general idea is to allow the user to override the tracing target with a macro attribute, e.g.

#[test_case::test_case(r#"value1")]
#[test_case::test_case(r#"value2")]
#[test_case::test_case(r#"value3")]
#[tracing_test::traced_test(target="shorter_name")]
fn the_test(line: &str)  {
    tracing::info!("meaningless info goes here");
    assert_eq!(line.len(), 6);
}

Would give output of:

2023-06-24T13:13:13.185821Z INFO shorter_name: crate::the_test: meaningless info goes here

Instead of:

2023-06-24T13:13:13.185821Z INFO value1_value2_value3: crate::the_test: meaningless info goes here
dbrgn commented 1 year ago

Hi, thanks for the PR!

I can see the use case, but I'm a bit unsure whether I should merge or not, given the increased complexity of the macro (and thus the increased maintenance burden). Especially since the main problem is caused by an interaction with another crate, and since nothing breaks (it's juts an inconvenience). If this is a very rare case, then I'd tend towards not including the contribution.

For now, I'll keep the PR open, and if other people think it's useful, please leave a comment!

inferiorhumanorgans commented 1 year ago

Ah, so I got that wrong. The long target name was being picked because I didn't give the variant an explicit name. I'm parsing apache logs so the input strings are pretty girthy.

However, it's a bit of an XY problem as my ultimate goal is to keep the log formatting during tests as terse as possible. For e.g. it'd be nice to hide the target completely as well as the timestamp and potentially even the level. For testing, IMO, that much detail isn't needed as the output is already grouped per test (and the target is going to be the same for the duration of the test anyhow).

dbrgn commented 4 months ago

For now, in the interest of keeping maintenance effort low, I'll close this pull request. If other people think this would be useful, please leave a comment or a 👍🏻 on the PR.