There is a (ongoing?) discussion about having one assert or multiple asserts in a test method of a test case.
Write Maintainable Unit Tests That Will Save You Time and Tears
My Unit Testing Idea : Facilitating Multiple Assertions
Avoid multiple asserts in a single unit test: revisited
The proponents of multiple asserts claim that (among others):
- multiple asserts make their test code shorter and thus,
- more readable,
- and faster to execute because the test setup is being re-used (which for time consuming test setups really is a matter).
The opponents claim that:
- one assert makes their test code more readable,
- only a little longer,
- and more reliable, because side effects of asserts are not an issue, because the individual test setup – the so called “fixture” if I am not mistaken – is recreated for every call to every test method.
The discussion is obscured by the fact that some are silently assuming a pragmatic point of view, meaning they accept unit test frameworks the way they are (without a realistic option to change and improve them).
(Note: Many test frameworks seem to implement failed asserts by throwing exceptions, thus leaving the test method, without a chance to proceed with the following assert. This is a limiting design of these frameworks, and they can be altered to be more flexible.)
The other group silently assumes the theoretical point of view, not accepting the state of unit testing frameworks, and implying that they should be altered if new insight, knowledge and wisdom demand it.
Limits of current frameworks
The current state of frameworks should not dictate whether multiple asserts are being used or not.
Reusing test setups (despite possible side effects)
If you accept that test setups must be reused in some cases to make the tests finish faster (despite the fact that side effects might make the wrong test fail), you have to run your test setup once for the group of asserts that you want to perform on the test setup.
How you achieve this differs:
- With one assert per test method you perform the setup at the top of the test method, for example.
- Similarly, with multiple asserts you perform the setup once by means offered by the programming language and the test framework (if the framework instantiates the individual test case class for every test method call (like CppUnit does) you use a static block (Java) or so).
The difference in code is negligible, in my opinion. This leaves the question whether other aspects can help determine whether one approach is better than the other. (If you know any, please speak up.)
Ignoring traditional unit testing structure
The proponents of multiple asserts per test method ignore some traditional unit testing structure: they ignore that the test setup is not to be done in the test method call itself, but this by itself is not of much importance. and can be ignored when considering theoretical aspects.
When it comes to practice however, one should probably use the supported (as said before, multiple asserts per test method call are not “supported” by many unit testing frameworks, in the sense that they do not execute asserts following a failed assert) and expected way, be it one assert or multiple asserts per test method call.
Test setup and asserts in one place – less indirection
What might make one assert per test method call code harder to read is the separation of test setup and asserts to be performed on them, because afterall the test setup is not being done in the same method, but elsewhere (and thus simply paging upwards won’t necessarily take you to the test setup, at least not very directly), which adds a level of indirection. (Because the human brain can only cope with a limited number of indirections any additional level of indirection should be considered with much caution).
Differences smaller than initially assumed?
Having said all this in so many words, maybe it helps to realize that one assert and multiple assert aren’t so terribly far apart as one would initially think, and that it is acceptable for oneself to follow one of both “styles” when it is required. Sure, with one assert per test method you have to add more methods, which means more lines of code. But they are pretty “empty” lines and easy to sort out for the eyes and brain.
