Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

one assert per test seems... as you said, indicative of zealotry. if you already have your object there, why not test for the changes you expect?

So you have one test that indicates that a log error is outut. then another that tests that the property X in the return from the error is what you expect. then another test to determine that propery Y in return is what you expect?

that to me is wasteful, unclear, bloated. About the only useful result I can see that is it allows bragging about how many tests a project has.



If two tests call the same method with the same setup and arguments just to assert two different outcomes I would suggest that is the code smell.


Yep, but that seems to be the prevailing convention being asserted (pun intended) by many commenters.


Furthermore, if you have a one-assertion rule, some bright spark will realize he can write a single assertion that checks for the conjunction of all the individual postconditions.

That's one way to get dogma-driven assertion roulette, as you will not know which particular error occurred.


If all assertions are at the end of the test, then yes. Sometimes this can be made nice with custom matchers, eg:

assertThat(fooReturningOptional(), isPresentAndIs(4))

Or

assertThat(shape, hasAreaEqualTo(10))

Or

AssertThat(polygonList, hasNoIntersections())

Custom matchers can go off the deep end really easily. One of those cases of learn the principle, then learn when it does not apply




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: