jimporter / mettle

A C++20 unit test framework
https://jimporter.github.io/mettle
BSD 3-Clause "New" or "Revised" License
122 stars 12 forks source link

Unexpected suppression of the tracing & Output customization proposal #33

Closed luav closed 6 years ago

luav commented 6 years ago

mettle unexpectedly suppresses original tracing (to both stdout and stderr) in both test cases (body of the _.test) and included headers, which is not always desirable and purely documented (implicitly mentioned only in the section Running Test, --show-terminal option).

The tracing suppression should be ~optional~ customizable with the possibility to redirect it to the log file(s) instead of just been silently omitted. Original debug build might assume post processing of the strout and stderr streams for the further testing & analysis, which can be retained parameterizing the output of the unit test results and original stdout/err streams to be performed to the specified file / stdout / stderr (besides the current --show-terminal option).

Also it would be nice to outline the default behavior (omission of tracing) in the main page / features description (https://jimporter.github.io/mettle/) mentioning that this behavior can be customized.

jimporter commented 6 years ago

Better docs would be nice here; I don't think I'd be willing to change the defaults, since I've been annoyed by debug spew from dependencies too many times to go back to seeing it all the time. It might make sense to add a little note next to the tests in the verbose log if there's output though. Like:

my test that prints to stdout PASSED [o ]
my test that prints to stderr PASSED [ e]
my test that prints to both PASSED [oe]

Maybe there's a clearer way to note it without it making the actual test results harder to read...

As for adding a log-to-file option, that makes sense, but I'm not 100% sure how I'd want to handle it (e.g. one file per invocation of mettle, one file per test run - i.e. running with -n, one file per test, etc.).

I'll probably spin this out into two (or three) issues though to make it easier to track.

luav commented 6 years ago

Yes, such notification ([o ], [ e]) for the discarded output (if given the non-empty output neither --show-terminal is specified nor the streams are redirected) would be very convenient and can be omitted for the --output equal to {silent, brief}.

As for the original stdout, stderr redirction then it would be nice to have the similarly named optional input parameters that denote the output file names for the respective original streams. In case -n is specified, then <n> can be added to the file name (retaining the possible file extension).
Also, It worth to consider whether --show-terminal functionality remains as it is now or the redirected stream should not be duplicated in the --show-terminal output since typically a large output is redirected. Ideally, --show-terminal should have an optional value {all, discarded} defaulted to discarded (non-redirected output).

Yes, it spins out into several tasks + docs extension.
@jimporter, thank you for the mettle maintenance and improvement!

jimporter commented 6 years ago

Ok, I've filed #34, #35, and #36 to handle each of the three things in here. Closing this in favor of those.