We all know that exercise is good for us, members of the species Homo Sapiens Sitonourasses. And yet most of us don’t do enough of it. The same is true for Test-Driven Development (TDD). But the similarity doesn’t end there.
With regular exercise, you can grow your muscles. The way this works is not linear, however. It follows an upward saw-tooth pattern: first you damage your muscles (training), then they heal (recovery) and eventually grow stronger than before (supercompensation), then you damage them again, etc:
TDD follows the Damage-Heal-Grow cycle as well.
First we damage the system by writing a test that fails. Where before we could gloat in knowing all was well because our test suite said so, now we have to admit that there is still something wrong with our code. For some, this realization may hurt as much as their sore muscles after working out.
Luckily, we heal the system quickly by writing only the minimal amount of code required to make the test pass. With everything back to green in minutes or even seconds, we have every right to feel good again. TDD is perfect for short-attention spans.
Finally we grow the system by improving the design. The system can now handle everything we’ve ever thrown at it and more, because we generalized concepts and gave them a proper place in the code.
Damaging and healing happen on two levels in TDD.
First there is the syntactic level. You write a test that calls code that doesn’t exist yet, so the code doesn’t even compile. The healing that follows is to make the code compile, even though it doesn’t yet pass the test.
Only after this syntactic healing do you change the code to pass the test. The latter is more of a semantic type of healing.
The distinction between syntactic and semantic healing has implications for how we work.
There are only so many ways that a program can be syntactically broken, and in many cases, a sophisticated enough IDE can help heal it. For example, when you write a test that refers to a class that doesn’t yet exist, Eclipse offers a Quick Fix to create the class for you.
Semantic healing, on the other hand, is more difficult. The transformations of the Transformation Priority Premise can be seen as standard building blocks, and at least some of them can be automated. But that’s still a long way from the IDE generating the code that will make the failing test pass.
I haven’t seen many TDD practitioners do the equivalent of walking around the beach showing off their rock-hard abs, and that’s probably a good thing.
But just as we appreciate how a strong, muscular friend can easily handle any piece of furniture when he helps us move, so do product owners like it that we can always deliver any feature in a short amount of time.
Unfortunately, it just doesn’t score us any dates; for that we really do need to hit the gym.
| Published on Java Code Geeks with permission by Remon Sinnema, partner at our JCG program. See the original article here: TDD is like working out Opinions expressed by Java Code Geeks contributors are their own. |
