GeePaw Hill, a software coach, spoke about five underplayed premises of TDD at eXperience Agile 2018. Key takeaways included: TDD is more than a technique; it’s a whole style of programming, an integrated system of related behaviors and ideas. The five premises of TDD provide a ring in which we operate, they are the air that a TDD’er breathes.
The five premises of test-driven development (TDD) form the kind of fundament under which almost all TDD proceeds, said Hill. They are really what is binding us into this test-driven approach in the first place.
The five premises that Hill presented were:
- The Money Premise — We’re in this for the money.
- The Judgment Premise — We’ll rely on individuals making local decisions.
- The Correlation Premise — Internal quality *is* productivity.
- The Chaining Premise — We’ll test mostly in very small parts.
- The Steering Premise — Tests & testability are first-class design participants.
When you are inside TDD these premises are invisible but still they are extremely important, argued Hill. You have to keep them in mind when doing TDD.
The money premise is about where the money is. TDD is not about testing, improving quality, or craftsmanship. The aim of TDD is to ship more value faster, said Hill, "we’re in this for the money".
The judgment premise implies that we are totally depending on individual humans using individual judgment. Software is doing the same thing every time, but the same is not true for humans, argued Hill. TDD is not an algorithm for coding; you have to take decisions when you are doing TDD.
The correlation premise says that internal quality and productivity are correlated. They have a direct relationship, go up together and go down together, said Hill, as they both depend on things like skills and domain knowledge. Keeping your code in good shape is not optional, argued Hill.
The chaining premise tells us that the way to test the chain is by testing each individual link in that chain. Programs are broken down in smaller parts; you have to do the testing on those parts. Testing the whole chain is expensive, it’s difficult to write the tests and maintain them, but testing the links is the cheapest way that will cover the most ground, said Hill.
The steering premise says that tests and testability are first class participants in design. If you don’t have a testable design, you don’t have a design, argued Hill. You are constantly questioning how to test this, and how it has been tested so far, all the way through from the very first line of code to the very last line of code that you write. You must change your design to make it as easy as possible to test, he said.
When you do TDD the premises will play a role during the work. They are invisible, the "air you breathe", argued Hill.
InfoQ spoke with GeePaw Hill after his talk.
InfoQ: What’s makes it so important to know the TDD premises?
GeePaw Hill: If we’re unaware of these premises, we can talk ourselves into some pretty serious foot-shooting behavior. For each of these, I could give an example, but let’s take the correlation premise.
TDD’ers are obsessed with the internal quality of their code, because they know it’s directly and immediately correlated with their productivity. Folks who don’t know that are prone to see work affecting the internal quality as "cleaning", a word I avoid assiduously. No matter how important one thinks it is to wash the dishes, the simple truth is that you can eat off dirty dishes for a long time and come to no harm. You can delay on the cleaning, because right now what you need is food, not cleaner plates. You want more food now, so you skip washing the dishes "just this once".
But what if not washing the dishes meant that you would immediately have less food now? Internal quality isn’t cleanliness because it’s a major factor in production, not a nice-to-have; the negative productivity effect of a poor factoring, a bad name, a long delay between the introduction of a variable and its initialization, is immediate. A person who understands the correlation premise never sees internal code quality as optional.
InfoQ: How can we improve our TDD skills?
Hill: TDD is often seen as a simple technique, but the argument of the premises is that it really is a whole style of programming, not a new tacked-on mechanic, but an integrated system of related behaviors and ideas. People who are skilled in karate are called karetekas, and in judo they’re called judoka. Going from the old-school styles to the modern synthesis is somewhat like going from being a kareteka to a judoka. It involves lots of different muscles, different movements, different ideas.
That having been said, there are really the same old things we have to do to get any rich skill:
- find a quiet safe place to open your mind to it.
- read around and study.
- practice, practice, practice.
There are teachers and mentors, and they can help you do all three of these things, but they can’t do them for you. As with all complex learning endeavors, there is no royal road to TDD.
