3 ms·
> One assert per test Was meant to make a failed test instantly communicate what's wrong with the unit under test. As frameworks evolve and our practices aroun
by rootlocus 5y ago
> One assert per test
Was meant to make a failed test instantly communicate what's wrong with the unit under test. As frameworks evolve and our practices around them change, it's absolutely fine to come up with new rules.
All of uncle Bobs rules come with pages of explanations of what problems they solve. If you don't have those problems, you may not need those solutions. The book is more about the spirit of the law than the letter.
- pydry 5y agoThis makes no sense whatsoever. I've read thousands of tests with multiple asserts that were perfectly plain about what was being tested and in many cases the logical sequence made it easier to understand. Breaking them into separate tests with one assert would simply have meant a shit ton more code to read. Uncle Bob's "rules" often come with mile long caveats that he seems to be blissfully unaware of. I think I get why he said it - overloaded tests are a thing - but he fucked up trying to turn his observation into a rule.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- MaxBarraclough 5y ago> > One assert per test > Was meant to make a failed test instantly communicate what's wrong with the unit under test. As frameworks evolve and our practices around them change, it's absolutely fine to come up with new rules. To put a finer point on that then, you're saying the rule is obsolete if your test framework allows assert statements to accept message strings?