

Testable Code vs. Clean Code - thewindev
http://thewindev.net/testable-code-vs-clean-code/

======
dalke
Based on your HN account name and the linked-to domain, I believe one person
is behind both, and I will use "you" to refer to that person.

"I was really happy to see that my code coverage was over 95%"

If you look at some of the TDD literature you'll find that some of its
advocates believe (or at least believed) that it would naturally lead to 100%
code coverage. For a semi-arbitrarily selected quote, from
[http://accu.org/index.php/journals/1325](http://accu.org/index.php/journals/1325)
:

> In theory, when using TDD we will always get 100 percent coverage (remember,
> we're only supposed to write code as an automated test fails).

and in my notes I have that Kent Beck wrote "TDD followed religiously should
result in 100% statement coverage."

I think your own experience shows that this statement isn't true. My
observation is that the refactor step implicitly allows new untested code
paths.

"But testable code will make your product more reliable, so you shouldn’t
chose between these two, but find a balance between them"

When I read your essay I wondered why you were focused on unit tests.
Integration tests can also be used to check that low-level accessors work.
While they don't pin down the error to the precise unit, this is also the sort
of error which is easy to track down once you know that an error exists, so
there isn't a strong need for a unit test over an integration test.

You might be interested in James Coplien's "Why Most Unit Testing is Waste" at
[http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-
Wa...](http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf) ,
and its followup at [http://www.rbcs-
us.com/documents/Segue.pdf](http://www.rbcs-us.com/documents/Segue.pdf) , as
well as plenty of discussion about it here on HN and elsewhere.

