Conversation

lol code coverage marks all my tracing::trace! statements as not covered because, well, I don't run tests with RUST_LOG=trace

which way would you go to solve that?

6
0
0

@fasterthanlime I'd set up a subscriber that accepts all logs but does nothing with them. Not sure if you'd have to write that yourself or if there's one already available as a crate.

1
0
0

@fasterthanlime the usual way. turn of the computer, destroy it, go to a forest, never come back

0
0
0

@sadlerap yeah that was my idea too. annoyingly I'd probably have to fork the test-log crate :/

0
0
0
@fasterthanlime What happens if you put on the feature that disables that kind of log statements?

https://docs.rs/tracing/latest/tracing/level_filters/index.html#compile-time-filters
0
0
1

@fasterthanlime either run with trace, or compile the trace level out at compile time for tests

it’s either a cargo feature or a cfg string for tracing

1
0
0

@brk @fasterthanlime yeah the latter is what i'd do, and a second non-code-coverage test run with tracing enabled because i'm super paranoid about "oops that panic only happens when constructing trace logs"

1
0
0

@iximeow @brk I'm experimenting with https://docs.rs/tracing/latest/tracing/level_filters/index.html but it doesn't look like this excludes them from coverage

1
0
0

I ended up rolling with my own tracing subscriber that always returns true for enabled() but conditionally skips recording events..

not a great solution but there are no great solutions

https://github.com/fasterthanlime/rc-zip/pull/79/files#diff-497ba6789db193e53d3e4e787e6aaf2fcd22d04ea18aa2cf6de9be6b26cab9e5R352-R404

0
0
0

@fasterthanlime In one project I have a similar but different problem that some `panic!()` or `unreachable!()` statements are not covered - but they're the type which could only be hit if there were a bug in the program. So if I knew of a way to hit them from tests, I'd have to fix it.

0
0
0