Why Most Unit Testing is Waste (2014) [pdf]
Wow so much fail. Where do these mickeymouse programmers repeatedly spring up? &quot;Oh, I&#x27;m a supermanprogrammer and I can get it just <i>right</i> the first time because I use my brain!&quot;<p>Sure I believe that there are people who can do this and get the code right by just thinking it through. But I have a question for even these people (and their organizations).<p>- What happens when these people leave and the new junior dev becomes the maintainer?
- What happens when the code is migrated&#x2F;reused somewhere else?
- How do you make sure your code works at least the same as it did before after you:
 * modify it
 * update some dependent component somewhere, say some open source library that your code uses internally. These have bugs too you know...<p>Simply you don&#x27;t unless you write the tests. The real value of testing (unit testing, regression testing, system testing) comes once you have that nice test suite and you can automate it and make sure that on every change nothing breaks. This is a beautiful thing to have, because simply no human can understand these software systems fully to make sure that some innocent looking change doesn&#x27;t break something. These things unfortunately happen.<p>Sure testing is hard if you make it so. I said before that I get an average ratio of about 2&#x2F;5 of actual code&#x2F;unit testing code. This doesn&#x27;t mean that &quot;this is so bothersome let&#x27;s not do it&quot;, what it should mean is that you <i>design</i> your system with testability in mind. A primary architectural goal in any design should be <i>testability</i> How easy it is to write unit tests for your classes and methods. The easier it is, the smoother the unit tests are to write and maintain and the better code quality you will have in the end.<p>Also note that when you design your software to be testable you get a few other abilities for free such as reusability. One of the most important starting points is to find the <i>right</i> separation of truly orthogonal components and define their interfaces right. Way too often I see code where the engineer didn&#x27;t understand this and clumped several unrelated concepts together. This really makes the testing hard and painful.