Write tests. Not too many. Mostly integration (2017)
I <i>so</i> agree with this. I&#x27;ve been fighting this exact battle at work lately. People on my team have decided to take testing seriously, which is fantastic, but many team members&#x27; understanding of what that means is still at the &quot;watch unit-test coverage numbers go up&quot; stage. So let me be very clear where I stand.<p><i></i>* 100% unit-test coverage is a garbage goal. <i></i>*<p>I don&#x27;t hate unit tests. They can have enormous value shaking out edge cases in a self contained piece of code - usually a &quot;leaf&quot; in the module dependency graph - and making it future proof. Love it. However, unit tests don&#x27;t tell you anything about whether the module&#x27;s behavior in combination with others leads to a correct result. It&#x27;s possible to chain a bunch of unit tests each with 100% coverage together, and still have the combination fail spectacularly. In operations, a lot of bugs live in the interstices between modules.<p>Even worse, 100% line coverage means a lot less than people seem to think. Let&#x27;s say one line to compute an expression will compute the wrong value for some inputs. You might have a zillion unit tests that cause that line to be counted as covered, but still be missing the test that reveals the error case. I see this particularly with ASSERT or CHECK types of macros, which get counted toward 100% coverage even though no test ever exercises the failure case.<p>Striving too hard for 100% unit test coverage often means a lot of work - many of our unit tests have 3x more tricky mock code than actual test code - to get a thoroughly artificial and thus useless result. The cost:benefit ratio is abominable. By all means write thorough unit tests for those modules that have a good ratio, but <i>in general</i> I agree with the admonition to focus more effort on functional&#x2F;integration tests. In my 30+ years of professional program, that has <i>always</i> been a way to find more bugs with less effort.