The tragedy of 100% code coverage (2016)
I find that, as I&#x27;m building something from scratch, the vast majority of the errors I make are just things I didn&#x27;t think of.  Tests don&#x27;t help there because I can&#x27;t test on input that I don&#x27;t even imagine happening.  So I generally write few tests, because, to be honest, most code is trivial and algorithm-light.  Sure, if I have to write a parser or something a bit more fiddly, I&#x27;ll write a unit test to be sure that it&#x27;s doing what I expect, but that tends to be the exception, not the rule.  I do write my code with an eye toward later testability if it turns out to be necessary, but I find that to be fairly easy, and also a good measure of if I&#x27;m doing the write thing: most code that isn&#x27;t testable is probably code that&#x27;s difficult to read and maintain, anyway, so if I look at something and think &quot;oof, how would I ever write a test for that?&quot; I&#x27;ll usually delete it and start over.<p>When I have something that should be working, I test it in a more functional&#x2F;integrative manner, and move on.<p>Later, I&#x27;ll write unit tests when I need to.  If I want to refactor something, or drastically change the implementation of something, I&#x27;ll write out some tests beforehand to be sure that the pre and post behaviors match.<p>I&#x27;ve always thought that TDD is just premature optimization.  You&#x27;re optimizing for the idea that you -- or someone -- will later need to make large enough changes to your code that you&#x27;d worry about breaking it.  In my experience that&#x27;s fairly rare, and you spend less time overall if you just write the tests as you need them, not up-front.  Yes, writing a test when the code is fresh in your mind will be faster than writing it much later, but then you&#x27;re writing a ton of test code that likely won&#x27;t be necessary.<p>An objection I hear to this is that you&#x27;re not just writing tests for yourself, you&#x27;re writing tests for the others who will need to help maintain your code, perhaps after you&#x27;re gone.  I&#x27;m somewhat sympathetic to this, but I would also say that if someone else needs to modify my code, they damn well better first understand it well enough such that <i>they</i> could write tests before changing it (if they deem it necessary).  Anything else is just irresponsible.<p>(Note that I primarily work in strongly statically typed languages.  If I were writing anything of complexity in ruby&#x2F;python&#x2F;JS&#x2F;etc., I don&#x27;t think I&#x27;d feel comfortable without testing a lot of things I&#x27;d consider trivial in other languages.)<p>(Also note that some things are just different: if you&#x27;re writing a crypto library, then you absolutely need to write tests to verify behaviors, in part because you&#x27;re building something that must conform to a formal spec, or else it&#x27;s less than worthless.)