Unit Testing Is Overrated
Unit tests have a purpose, which is mostly to protect <i>the programmer</i> against <i>future</i> mistakes. Integration and system tests protect the <i>user</i> against <i>current</i> mistakes.<p>I&#x27;ve been on projects that focused almost exclusively on unit tests and on projects that focused almost exclusively on integration tests. The latter were far better at shipping actually working code, because most of the interesting problems occur at the boundaries between components. Testing each piece with layer after layer of mocks won&#x27;t address those problems. Yay, module A always produces a correct number in pounds under all conditions. Yay, module B always does the right thing given a number in kilograms. Let&#x27;s put them together and assume they work! Real life examples are seldom this obvious, but they&#x27;re not far off. Also note that the prevalence of these integration bugs <i>increases</i> as the code becomes more properly modular and especially as it becomes distributed.<p>I firmly believe that integration tests with fault injection are better than unit tests with mocks <i>for validating the current code</i>. That doesn&#x27;t mean one shouldn&#x27;t write unit tests, but one should limit the time&#x2F;effort spent refactoring or creating mocks for the sole purpose of supporting them. Otherwise, the time saved by fixing real problems more efficiently - a real benefit, I wouldn&#x27;t deny - is outweighed by the time lost chasing phantoms.