When tests are small, a test failure means just one thing – somewhere in these ten lines of code which are being tested, there is an error. Ok, sometimes this can mean that there is an error in the test script, or a there is a failure, or change of expectation, but fundamentally, it pin-points the cause of the failure to a small target, which usually means that debugging becomes trivial.
When an end to end acceptance test fails, the failure could be due to any one of a large number of source lines or expectations changes across a large body of code. Debugging may be quick, but often isn’t.
Small tests run faster too! While a typical small test may take 10 milliseconds to run, a large acceptance test may take twenty minutes.
Just a small back of the envelope calculation tells us that if a developer checks in twice a day and saves an hour each time because potential issues had been found before check-in with fast small tests, and the faster feedback, or has reduced their time spent debugging – that is two hours a day per developer that could be put to better use.
2 hours a day * thirty developers * two working weeks = 600 additional hours per two week iteration available.
This is equivalent to adding seven and a half developers to the team!
What value do you get from tests of different sizes?