“Why do you want me to write wong code?” an attendee asked me in the break of one of my test driven development trainings.
At first, I did not understand the question: “No, in an ideal world, I only want you to write correct code! That’s why I teach these trainings.”
Then he explained…
In today’s video, I want to show you that there are different kinds of progress you make when doing TDD and that each test should advance your program on one of those axis. I will also discuss why it is important to write what this attendee called “wrong code”.
My name is David, and in this video series, I want to show you techniques and tricks that I use myself and teach others to use.
By the way, if you like this video, please share it using the share buttons on the left.!
Question / Problem
In my trainings, I usually ask attendees to write a short program in a test-driven way on their own. And after that, we do the same exercise again together. Only this time, I stop them when they make a mistake, I nudge them to take small steps and I help them when they get stuck.
The question came after this second exercise.
“You wanted us to return a single underscore, and we already knew that this would not be the final implementation. We knew we would change this code five minutes later. You forced us to write wrong code!”
OK, if you put it like that, I wanted them to write wong code. The simple solution would be to answer: “The code was right at the time. It passed all tests we had so far”.
But there is more to that.
Two things are important here:
- Axis of progress
- Enabling the next red test
When we do one TDD cycle - red, green, refactor - we usually make progress on one or more of these axis:
- The test suite
- The design of the production code
- The features of the system under test
This test and its implementation meant progress in the test suite: We now have a first, correct test that must always pass from now on. And it meant progress in the design of the production code: We now know how we want the
Hangman class to keep the secret and to generate the hint.
It did not advance the “features” axis, but our next tests will do that.
This truly simplistic implementation also enables the next red test. Had we written a more complete - a more correct implementation, we would have a hard time to write the next test so that it is both
- Failing (Red) and
So, taking these small steps is important because it enables you to write the next red test. And it is OK to write code that will be proven to be “wrong” later, as long as it is correct at the time you wrote it.
Even those small steps will mean progress at least on some of the three axis
- Test suite
And that’s it for this week. What do you think about those small steps? Did this video answer some questions, or did it raise new ones? Tell me in the comments or on Twitter, where I am @dtanzer.
And if you liked this video, please subscribe and share it with your friends and followers using the share buttons below - That would be awesome!
Read / watch all parts of this series here:
- TDD: Red-Green Part 8: Conclusion
- TDD: Red-Green Part 7: Specific / Generic
- TDD: Red-Green Part 6: Triangulation
- TDD: Red-Green Part 5: Into a Corner
- TDD: Red-Green Part 4: List of Goals
- TDD: Red-Green Part 3: Why Red
- TDD: Red-Green Part 2: Wrong Code
- Red-Green Part 1: Introduction
- Red, Green, ... Part 0: All Posts