Timeline for Is it OK to have multiple asserts in a single unit test?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 31, 2017 at 11:09 | comment | added | Anestis Kivranoglou | i think that Judging the severity of the failure by how many tests have broken is like measuring productivity by lines of code. I can write 40 tests that test the same functionality with different values. If this single functionality fails that wouldn't mean that its 40 times bad! I can just test it with 1 assert of one value! but well adding some more assert values would just make the test more secure with minor overhead. | |
| Jun 16, 2016 at 6:03 | comment | added | Juha Untinen | I think the point is to have the tests be useful to other team members too. Possibly someone who just started. If they do a change that breaks something elsewhere (encapsulation notwithstanding), it could be useful to show all the errors. | |
| Jun 11, 2016 at 15:40 | comment | added | gnasher729 | @Restuta: If I break one thing then it's broken and needs fixing. If I break five things then it's broken and needs fixing. No difference. Five tests with one assert each, or one test with five asserts, I learn about the breakage and that's the important thing. | |
| Jun 2, 2016 at 21:09 | comment | added | Restuta | @gnasher729 it would be useful if you specified why, I could disagree in more constructive manner. In the meantime I'll try to explain why number is of big importance. When you make a change and break 1 test it may suggest that it's a minor break and easy to fix. And when you see you broke 5, it may suggest that this is more things to fix and tell what what exactly broke to give your more context, so you can take more informed decision. So not only number of tests matters, but test names and failure messages do as well. | |
| Jun 2, 2016 at 9:27 | comment | added | gnasher729 | @Restuta: It's useful to know if the number of failures that you created is 0 or not. The number is of very little importance. | |
| Mar 23, 2014 at 7:20 | history | edited | Alexander | CC BY-SA 3.0 | Added syntax highlighting |
| Mar 29, 2013 at 17:44 | comment | added | Kazark | @Sly Tho this problem is being mitigated by some frameworks (Google Tests is the only major one I know of) which are now implementing the concept of expects. A test can have multiple expects and if they all fail, they will all be shown as failing. | |
| Mar 22, 2012 at 1:42 | comment | added | Restuta | you should care about other tests, because it's useful to know how many assertions you broke by your change. And to see that full picture for the first time, not step-by-step fixing assertions one-by-one. | |
| Aug 15, 2011 at 12:02 | comment | added | maaartinus | @Sly: Yes, I don't get information from the later asserts. Should I care? When I fix the first problem, most probably the other asserts will pass as well. If not, I'll fix them. In the - very rare - cases I need more information at the beginning I can write an additional test. | |
| Jun 25, 2011 at 4:28 | comment | added | ratkok | google C++ testing framework has ASSERT() and EXPECT(). The ASSERT() stops on failure while EXPECT() continue. That's very handy when you want to validate more than one thing in the test. | |
| Feb 6, 2011 at 8:47 | comment | added | Restuta | Can you give an example of a tool that continues? | |
| Sep 28, 2010 at 23:21 | comment | added | JBRWilkinson | @Sly: if the testing tool bails out when at the first failed assert, then you're right. If the tool continues until an unrecoverable condition (unexpected exception), multiple asserts would be valid. | |
| Sep 28, 2010 at 12:03 | comment | added | Matt Ellen | @Restuta: I had no idea you could do that! I'm using MbUnit, and have found a similar attribute: RowAttribute, so I can compress the above test, after the refactoring the last two asserts. | |
| Sep 28, 2010 at 11:12 | comment | added | Restuta | Your case is very representative, that is why NUnit has additional attribute TestCase - nunit.org/?p=testCase&r=2.5 | |
| Sep 28, 2010 at 11:00 | comment | added | Matt Ellen | I fix my problems one at a time. So the fact that the test could fail more than once doesn't bother me. If I split them up I would have the same errors come up, but all at once. I find it easier to fix things a step at a time. I admit, that in this instance, the last two assert could probably be refactored into their own test. | |
| Sep 28, 2010 at 10:55 | comment | added | cringe | Do you consider it still bad if all the asserts test the same kind of functionality? Like above, the example tests the conditionals and if any of this fails, you should fix it. Does it matter to you that you may miss the last 2 asserts if an earlier one fails? | |
| Sep 28, 2010 at 10:52 | comment | added | Sly | Multiple asserts are bad because of error detection. If you have failed your first Assert.IsTrue, other asserts will not be executed, and you won't get any information from them. On other hand if you had 5 tests instead of 1 with 5 asserts you could get something usefull | |
| Sep 28, 2010 at 10:49 | history | answered | Matt Ellen | CC BY-SA 2.5 |