During the review of several unit tests in different projects, there are usually tests containing output statements (such as System.out.println or file output). My initial opinion to outputs in tests, especially to console outputs, is that they should be avoided in any case.
When thinking further, it seems to me that gathering data in a file could be legitimate for some situations. But console output still should be avoided in general. The assertXXX-methods or the fail-method allow for displaying any message the developer wants. So outputs to other channels (console, file etc.) need a different motivation.
What could be the motivation for a console output? Maybe to display informal messages to the developer, such as warnings or pure information. For the latter, the motivation seems not strong enought to me for justifying the console output. For the former, I could image that for such console output certain circumstances could apply of which I could not name one concretely, now. However, instead of using warnings, a unit test should fail or not fail, nothing in between, IMO. A unit test should have the chance being fine-grained enough to fulfill this postulation quite easily.
For file output or related (such as sending an email to an admin, although I have not seen this in any unit test, luckily) one could think of keeping track of statistical data to recognize a "tendendy" of behaviour, e.g. for logic depending on pseudo-randomism such as hashcodes.
To conclude, I still think in most cases it causes more harm than do good using console or file outputs.
Do you have an example where such output would be justifyable in a unit test?
2 comments:
Testing an error logging utility is an example of where one would want to check the output to the console.
The problem with console output is that you cannot verify automatically what has been output.
Instead of usign the console redirect the output to a stream and then test against the stream!
So in your case you do no need a console output either.
Post a Comment