Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Lessons Learned
As we progressed, we found that it was easier for me to work as a pair-partner in the elaborative phase. When I paired in the generative phase, I had to work on my timing and be sensitive to the creative work required in that phase. Constantly firing out test ideas could severely impede progress. James Bach has likened this process to reading a memo over someone’s shoulder as they type it, pointing out every grammatical error and typo as they type. It’s far more productive to let the writer get those initial ideas out, and edit from there. As John and I worked together, I learned to pick up on cues and listen more. I could recognize what phase we were in by the questions John would ask—often he would just want to bounce ideas off me—or by where we were in development. I learned to ask clarifying questions to be sure that I wasn’t overwhelming development. We used to joke that I would unleash the fire hose of testing ideas too soon, so I’d sometimes clarify when transitioning from the generative phase to the elaborative phase to see whether the programmer was ready to "drink from the test idea fire hose."
Some specific lessons I learned as a tester working with a developer during TDD:
- Don’t make assumptions about TDD until you’ve tried it.
- Start working with developers in the elaborative phase, and work into the generative phase.
- Be prepared to give all sorts of feedback on the emerging design, not just test idea generation and bug reports.
- Learn to watch for "code smells" in the design.
- TDD-derived tests can also serve as a form of product documentation. A great way to get up to speed on an application is to look at the tests.
- Don’t get too caught up in testing only in the code context. You can test at the user interface context and the system context as well as the code context, and find useful information in each context.
True TDD looks like this:
- Write a test.
- Write enough code to get the test to pass.
- Write a new test.
- Write enough code to get that test to pass.
- Repeat.
- Look at testability in the design. If the new tests you’re writing are awkward, refactor them using the automated unit tests as a safety net.
It’s difficult to really understand test-driven development until you actually try it. Being trained by an expert programmer helped me to learn how to do TDD properly. Once I had experienced TDD with an expert, I was ready to practice it on my own. Part 2 of this series describes that experience.