Timeline for Is it OK to have multiple asserts in a single unit test?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3, 2021 at 9:12 | comment | added | Wolfzoon | @OSGIJava This is the mentioned paradigm "You can have one date object as seen in your code and 3 separate tests using it. " Which GreenGrassoHolm interpreted as "start with string, do date.parse in each test to test one 'thing' in result". Hence "extract data from worksheet in each test to test one row in result". Did you mean the Date.Parse to take place in the testing fixture, and the three tests to only consist of assertions? Or first a test that parsing succeeds, storing the Date for other tests? Either would break "Arrange, Act, Assert" like crazy. | |
| Jul 3, 2021 at 19:27 | comment | added | OSGI Java | @GreenGrassoHolm Would you please provide a link to the paradigm you mentioned? Alternatively, you could write your own custom Assert which would compare all 3 date units and print out the parts which fail the test. So it would be a single Assert printing out all the failures. | |
| Jul 2, 2021 at 18:16 | comment | added | Green Grasso Holm | Alternatively, I can call the extraction method just once, in the test setup code, but then I'm breaking a different paradigm: the one under which each test method is structured as arrange, act, assert: I'd only be asserting, with all the arranging and acting happening in the setup code. Paradigms at loggerheads. | |
| Jul 2, 2021 at 18:13 | comment | added | Green Grasso Holm | @OSGIJava that implies that you have three tests, each of them calling the same method before making its one assertion. Likewise, if I have a single method that extracts data from a worksheet and I want to check that it comes up with exactly the 177 values I expect it to, instead of running the extraction once and then checking the 177 values, I'd have to have rerun my test setup and call the extraction method 177 times, and assert only one of those facts after each, just so I can say I'm following someone's recommended paradigm for unit testing. | |
| Oct 6, 2020 at 23:39 | comment | added | OSGI Java | You can have one date object as seen in your code and 3 separate tests using it. The you can have 3 tests: 1. expect year to be equal 2. expect month to be equal 3. expect day to be equal The advantage is that there would be only one reason for failing these individual tests: 1. year parser is broke 2. month parser is broke 3. day parser is broke The bottom line is that this is not a good example to support your claim. | |
| S Jun 2, 2016 at 11:00 | history | answered | Pete | CC BY-SA 3.0 | |
| S Jun 2, 2016 at 11:00 | history | made wiki | Post Made Community Wiki by Pete |