My dislike for what I call 'perverse Test Driven Development'
July 25, 2012
There is a particular style of TDD that I will call 'perverse TDD' for lack of a better name. In perverse TDD, you are supposed to very literally write the most minimal code possible to pass a new test, even if the code is completely useless and artificial. The ostensible justification and excuse for this is that this makes sure you have tests for all of your code (taken from this site on TDD Django development, because reading its writeup on this is what pushed me over the edge today).
I hate this approach and it drives me up the wall. I think it's a stupid and wasteful way to work, and besides it doesn't really achieve its stated goals. It's very hard (and wasteful) to test enough to defeat serious perversity in the code under test, and it's inefficient to repeatedly rewrite your code (always moving towards what you knew from the start that you were going to write) as you write and rewrite a series of slightly smarter and more specific tests. In fact it's more than merely inefficient; it's artificial make-work.
I see the appeal of having relatively complete tests, but I don't think perverse TDD is the way to get to it. If you need thorough tests, just write a bunch of tests at once and then write the real code that should satisfy them. If you're writing the real code and you find important aspects of it that aren't being tested, add more tests. Tests and code do not exist in an adversarial relationship; attempting to pretend otherwise is fooling yourself.
(Indeed, as the TDD Django writeup shows, at some point even people who do perverse TDD deviate from their strict and narrow path in order to write real code instead of the minimal code that passes the tests. This is because programmers are ultimately not stupid and they understand what the real goal is, and it is not 'pass tests'.)
I feel that perverse testing is in the end one sign of the fallacy that everything can or should be (unit) tested. There are plenty of things about your code that are not best established through testing and one of them is determining if you are testing for enough things and the right things.
* * *
Atom feeds are available; see the bottom of most pages.