What Makes a Good Unit Test? says that a test should test only one thing. What is the benefit from that?
Wouldn’t it be better to write a bit bigger tests that test bigger block of code? Investigating a test failure is anyway hard and I don’t see help to it from smaller tests.
Edit: The word unit is not that important. Let’s say I consider the unit a bit bigger. That is not the issue here. The real question is why make a test or more for all methods as few tests that cover many methods is simpler.
An example: A list class. Why should I make separate tests for addition and removal? A one test that first adds then removes sounds simpler.
I’m going to go out on a limb here, and say that the ‘only test one thing’ advice isn’t as actually helpful as it’s sometimes made out to be.
Sometimes tests take a certain amount of setting up. Sometimes they may even take a certain amount of time to set up (in the real world). Often you can test two actions in one go.
Pro: only have all that setup occur once. Your tests after the first action will prove that the world is how you expect it to be before the second action. Less code, faster test run.
Con: if either action fails, you’ll get the same result: the same test will fail. You’ll have less information about where the problem is than if you only had a single action in each of two tests.
In reality, I find that the ‘con’ here isn’t much of a problem. The stack trace often narrows things down very quickly, and I’m going to make sure I fix the code anyway.
A slightly different ‘con’ here is that it breaks the ‘write a new test, make it pass, refactor’ cycle. I view that as an ideal cycle, but one which doesn’t always mirror reality. Sometimes it’s simply more pragmatic to add an extra action and check (or possibly just another check to an existing action) in a current test than to create a new one.