Why Most Unit Testing Is Waste [pdf]
The normal practice for large scale codebases in complex domains is &quot;the code is the spec&quot;. That is, the only specification for how the system should work is how it worked yesterday. 
In that case, unit tests serve as a great specification. Even tests that just duplicate the business code under test and assert that it&#x27;s the same (A huge waste in normal cases) is useful. Because a Unit test is much better than a word document in describing how code should behave. I very much prefer a massive, hard to maintain set of poorly written unit tests, to a large number of outdated documents describing how every bit of the system should work.<p>So is a big&#x2F;bad test suite a burden? Sure. But is it a burden compared to maintaining specifications of other kinds? Is it a burden compared to working in a system with neither type of specification?<p>Further, the people writing long articles like this are (or at least were) very good developers. There is often an element of &quot;good developers write good code, so just use good developers&quot; in them. But writing good software with good developers was never the problem. The problem is making software that isn&#x27;t terrible, with developers ranging from good to terrible, and most being mediocre.