<story><title>Why Most Unit Testing Is Waste [pdf]</title><url>https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf</url></story><parent_chain><item><author>mattmanser</author><text>The article addresses your first point in a big section:&lt;p&gt;1.4 The Belief that Tests are Smarter than Code
Telegraphs Latent Fear or a Bad Process&lt;p&gt;Your other point about only good programmers not needing unit tests is moot as you haven&amp;#x27;t followed it through to the conclusion. Namely, if bad programmers write bad code that needs unit tests, they&amp;#x27;re also going to write bad unit tests that don&amp;#x27;t test the code correctly. So what&amp;#x27;s the point?</text></item><item><author>alkonaut</author><text>The normal practice for large scale codebases in complex domains is &amp;quot;the code is the spec&amp;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&amp;#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.&lt;p&gt;So is a big&amp;#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?&lt;p&gt;Further, the people writing long articles like this are (or at least were) very good developers. There is often an element of &amp;quot;good developers write good code, so just use good developers&amp;quot; in them. But writing good software with good developers was never the problem. The problem is making software that isn&amp;#x27;t terrible, with developers ranging from good to terrible, and most being mediocre.</text></item></parent_chain><comment><author>ekidd</author><text>&amp;gt; Namely, if bad programmers write bad code that needs unit tests, they&amp;#x27;re also going to write bad unit tests that don&amp;#x27;t test the code correctly. So what&amp;#x27;s the point?&lt;p&gt;Let&amp;#x27;s assume you hire &lt;i&gt;good&lt;/i&gt; programmers, because otherwise you&amp;#x27;re doomed. But oftentimes, the &amp;quot;good&amp;quot; programmer and the &amp;quot;bad&amp;quot; programmer are the same person, six months apart:&lt;p&gt;1. John writes some good code, with good integration tests and good unit tests. He understands the code base. When he deploys his code, he finds a couple of bugs and adds regression tests.&lt;p&gt;2. Six months later, John needs to work on his code again to replace a low-level module. He&amp;#x27;s forgotten a lot of details. He makes some changes, but he&amp;#x27;s forgotten some corner cases. The tests fail, showing him what needs to be fixed.&lt;p&gt;3. A year later, John is busy on another project, and Jane  needs to take over John&amp;#x27;s code and make significant changes. Jane&amp;#x27;s an awesome developer, but she just got dropped into 20,000 lines of unfamiliar code. The tests will help ensure she doesn&amp;#x27;t break too much.&lt;p&gt;Also, unit tests (and specifically TDD) can offer two additional advantages:&lt;p&gt;1. They encourage you to design your APIs before implementing them, making APIs a bit more pleasant and easier to use in isolation.&lt;p&gt;2. The &amp;quot;red-green-refactor-repeat&amp;quot; loop is almost like the &amp;quot;reward loop&amp;quot; in a video game. By offering small goals and frequent victories, it makes it easier to keep productivity high for hours at a time.&lt;p&gt;Sometimes you can get away without tests: smaller projects, smaller teams, statically-typed languages, and minimal maintenance can all help. But when things involve multiple good developers working for years, tests can really help.</text></comment>
<story><title>Why Most Unit Testing Is Waste [pdf]</title><url>https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf</url></story><parent_chain><item><author>mattmanser</author><text>The article addresses your first point in a big section:&lt;p&gt;1.4 The Belief that Tests are Smarter than Code
Telegraphs Latent Fear or a Bad Process&lt;p&gt;Your other point about only good programmers not needing unit tests is moot as you haven&amp;#x27;t followed it through to the conclusion. Namely, if bad programmers write bad code that needs unit tests, they&amp;#x27;re also going to write bad unit tests that don&amp;#x27;t test the code correctly. So what&amp;#x27;s the point?</text></item><item><author>alkonaut</author><text>The normal practice for large scale codebases in complex domains is &amp;quot;the code is the spec&amp;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&amp;#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.&lt;p&gt;So is a big&amp;#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?&lt;p&gt;Further, the people writing long articles like this are (or at least were) very good developers. There is often an element of &amp;quot;good developers write good code, so just use good developers&amp;quot; in them. But writing good software with good developers was never the problem. The problem is making software that isn&amp;#x27;t terrible, with developers ranging from good to terrible, and most being mediocre.</text></item></parent_chain><comment><author>alkonaut</author><text>My point was that even bad unit tests are better than both good&amp;#x2F;bad word docs or no unit tests. So even bad tests written by bad programmers have a value. They have a large COST too (which is what he&amp;#x27;s arguing), my argument was merely that the value might not be less than the cost, which is his assertion.&lt;p&gt;&amp;gt; Software engineering research has shown that the most costeffective
&amp;gt; places to remove bugs are during the transition from
&amp;gt; analysis to design, in design itself, and in the disciplines of
&amp;gt; coding. It&amp;#x27;s much easier to avoid putting bugs in than to take
&amp;gt; them out.&lt;p&gt;Everyone knows that. It&amp;#x27;s just beating a dead horse. But companies demonstrably want to ship buggy and feature rich software fast, rather than ship well designed and lean software. And b) don&amp;#x27;t want to pay for developers of the kind that write good code from the beginning. So with that out of the way, the whole point of real world development methodology is to make sure that the feature-bloated code hastily written by average developers doesn&amp;#x27;t lack a specification, doesn&amp;#x27;t deteriorate over time into something that has to be abandoned, and doesn&amp;#x27;t have such a high risk of modification&amp;#x2F;refactoring that it can&amp;#x27;t be maintained.&lt;p&gt;Now there are some good points to 1.4 &amp;quot;code is better than tests&amp;quot; actually applies: make asserts in the code rather than in the tests, where possible. Fully agreee with that. Or even better I&amp;#x27;d say: don&amp;#x27;t &amp;quot;assert&amp;quot; things, just make the invalid state impossible. This is what types are for. If you can&amp;#x27;t take a null into a method, don&amp;#x27;t even accept an object that could be null by accident. Accept an Option type. Yes even in Java. Even in bloody C. Anything that a compiler could have caught shouldn&amp;#x27;t be either a runtime assert &lt;i&gt;nor&lt;/i&gt; a test.&lt;p&gt;&amp;gt; if bad programmers write bad code that needs unit tests, they&amp;#x27;re also going to write bad unit tests that don&amp;#x27;t test the code correctly. So what&amp;#x27;s the point?&lt;p&gt;Well firstly they are usually better than no tests. And second, they tend to fail too often, rather than too little. This is what causes the enormous cost incurred by these tests. But apart from that 90% unnecessary cost (test failures are failures of the code rather than the costs, so after changing the code you have to change the test) - they still do add a lot of confidence for refactoring. Because in my experience with a large but bad test suite, there are often false positives but false negatives are much rarer.</text></comment>