Add option to filter output

[biffen]

I.e. --quiet/-q to reduce the output to just the ‘bad’ stuff (failed tests and their details).

This would produce invalid TAP, but it would mainly be meant for human consumption.

[ghost]

Filtering out printfs from the code itself would be great, also. Great library by the way, thanks for making it.

[biffen]

@bright-star Thanks for the kind words.

I'm afraid, however, I don't quite understand your request. Could you clarify what you mean?

[ghost]

If some portion of the code under test prints to the std streams, the test output will mix those in with the TAP results. I don't use any TAP readers, but the visual noise can be significant. I'm not sure if this is possible with C++ or not, but suppressing output from anything that isn't BugEye's entry point itself would solve this.

For an example, here is the repo I was trying BugEye out with. If you run make check you can see warning messages from the library in the test output.

[biffen]

I don't know of a good way of doing that. The only thing I can think of would use preprocessor hackery, and I definitely don't want to do that in a library.

There are two other ways:

1. You could wrap your printing in #ifndef TEST–#endif.

2. You could stop printing directly to STDOUT in your code: Use some form of logging instead, and turn it off when testing.

Frankly I find the latter to be the better option, as I as a user of your library wouldn't want it to uncontrollably print things. It's not a very Nice Thing™ to do.

[ghost]

That's true.

[biffen]

For clarification, both to @bright-star and to anyone coming across this conversation:

I realise my previous comment may be perceived as a ‘my code is perfect, it's you who should change’ type comment. That is most certainly not the intention.

The idea of disabling printing to STDOUT (and STDERR) by any code other that of BugEye itself is an interesting one. I would like to be able to implement it, but it would have to be a good implementation; one that doesn't interfere and preferably doesn't use any preprocessor hackery.

That being said, I do (personally) think that code that should be unit tested shouldn't ordinarily print anything, or at least be easily configurable not to. This is especially true for library code: I as a library user would expect to be in charge of what gets printed, and I'd be surprised if a call to a library function had such side effects.

This doesn't, however, invalidate the feature request. It may be implemented in the future (although not under this particular issue).

In summary

• The feature request is of interest,
• but not part of this issue.
• There's a well-defined (and documented) workaround, albeit a somewhat intrusive one.
• It is not for BugEye or myself to say how the tested code ‘should’ behave,
• but in this case I believe a ‘fix’ would also improve the overall quality of the code in question.

---

The general attitude of BugEye is one of accommodation and adaptation. If it doesn't work well with a particular piece of code let us know and we shall try to solve it.