<story><title>The tragedy of 100% code coverage (2016)</title><url>http://labs.ig.com/code-coverage-100-percent-tragedy</url></story><parent_chain><item><author>iamleppert</author><text>The worse the developer, the more tests he&amp;#x27;ll write.&lt;p&gt;Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive &amp;quot;test suite&amp;quot; to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there.&lt;p&gt;Tests will be poorly written, pointless, and give an overall false sense of security to the next sap who breaths a sigh of relief when &amp;quot;nothing is broken&amp;quot;. Of course, that house of cards will come down the first time something is in fact broken.&lt;p&gt;I&amp;#x27;ve worked in plenty of those environments, where there was a test suite, but it couldn&amp;#x27;t be trusted. In fact, more often than not that is the case. The developers are a constant slave to it, patching it up; keeping it all lubed up. It&amp;#x27;s like the salt and pepper on a shit cake.&lt;p&gt;Testing what you do and developing ways to ensure its reliable, fault-tolerant and maintainable should be part of your ethos as a software developer.&lt;p&gt;But being pedantic about unit tests, chasing after pointless numbers and being obsessed with a certain kind of code is the hallmark of a fool.</text></item></parent_chain><comment><author>swalsh</author><text>&amp;quot;The worse the developer, the more tests he&amp;#x27;ll write.&amp;quot;&lt;p&gt;no.... please..... no..... let&amp;#x27;s not go down this path.  Why does everything have to be extreme?  No tests, 100% tests... it&amp;#x27;s all bollocks.&lt;p&gt;The most robust code I&amp;#x27;ve ever written was 100% because of unit tests.  It was a little engine that approved the prior authorization for medications.  The unit tests didn&amp;#x27;t cover 100% of the application.  In fact the only bit it did cover was the various use cases in the approval logic.  The tests were invaluable in writing the logic, and continued to be invaluable for the maintenance of the project.&lt;p&gt;Tests are a tool.  You don&amp;#x27;t need to use the tool for EVERYTHING, but sometimes it&amp;#x27;s the best tool for the job.  Using it doesn&amp;#x27;t make you a bad developer, using it badly makes you a bad developer.</text></comment>
<story><title>The tragedy of 100% code coverage (2016)</title><url>http://labs.ig.com/code-coverage-100-percent-tragedy</url></story><parent_chain><item><author>iamleppert</author><text>The worse the developer, the more tests he&amp;#x27;ll write.&lt;p&gt;Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive &amp;quot;test suite&amp;quot; to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there.&lt;p&gt;Tests will be poorly written, pointless, and give an overall false sense of security to the next sap who breaths a sigh of relief when &amp;quot;nothing is broken&amp;quot;. Of course, that house of cards will come down the first time something is in fact broken.&lt;p&gt;I&amp;#x27;ve worked in plenty of those environments, where there was a test suite, but it couldn&amp;#x27;t be trusted. In fact, more often than not that is the case. The developers are a constant slave to it, patching it up; keeping it all lubed up. It&amp;#x27;s like the salt and pepper on a shit cake.&lt;p&gt;Testing what you do and developing ways to ensure its reliable, fault-tolerant and maintainable should be part of your ethos as a software developer.&lt;p&gt;But being pedantic about unit tests, chasing after pointless numbers and being obsessed with a certain kind of code is the hallmark of a fool.</text></item></parent_chain><comment><author>arekkas</author><text>&amp;gt; The worse the developer, the more tests he&amp;#x27;ll write.&lt;p&gt;As always, generalization is the tool of the fool (sorry for the fool part, but it rhymes ;) ). Writing pointless stubs &amp;#x2F; mocks and testing execution order of statements is definitely a bad pattern, writing many and good functional, e2e and integration tests however is not.</text></comment>