Feed on

In the early days of a transition, we gird our loins and take up the lance, however unlikely our ultimate victory, and set ourselves to oppose the biggest TDD inhibitor, the minds of our developers.

Use all of the coaching pillars to help instill the message:

  • Situate by teaching and explaining the beliefs.
  • Model by living them publicly.
  • Invite by having fun writing microtests.
  • Sort by leaving time for skill development.
  • Release by letting them manage the ‘must-test’ list.

Required Understandings

Each of the sections below is a statement of belief we want all of our developers to be conversant and comfortable with.

Imagine your teammates talking to members of a non-TDD team. If they can spontaneously explain and defend their behaviors using these beliefs, we’ll have won most of the battle.

We’re In This For Productivity

You know my rant on this one. TDD is not about quality, it’s about speed.

I often use the comical fact of ‘night-coding’, i.e. programming for your own amusement.

When I’m night-coding, I rarely write storytests. Storytesting is expensive on code not built for it, and besides, storytests are really a collaborative tool. I already collaborate well with me, so I skip storytesting. (Some agilists are disappointed with me about this. I tell them to go to the back of the complaints line.)

On the other hand, I always use microtests, even for night-code. Driving development by microtesting is a productivity tool. Even when I’m in the privacy of my own back porch, I want productivity. Everybody wants productivity.

There’s No Free Lunch

But don’t kid yourself. TDD is not free.

Some ideas are simple facts, really. Once a C++ programmer learns why she should default to ++i rather than i++, it’s pretty easy to just always do it without much thought. Simple facts deliver their value instantly.

TDD is not a simple fact, it’s a whole way of programming.

Ask people how long it took for them to learn programming in the first place. The good news is that it will take much less time to learn TDD, because they already know the syntax, the tools, and the problem domain. This time they just have to understand a loose cluster of a couple dozen techniques.

But it ain’t free. Your team is going to have to practice practice practice. Make them — and their managers — completely relaxed about this.

We’ll Adopt TDD Sanely

Remember the sit-in-your-own-lap transition? How can we get TDD all-at-once-a-little-at-a-time?

We make a list of classes called the ‘must-test list’. If a developer is going to touch a must-test class, she has to use full-on TDD: microtests written before changes, the ol’ red-green-refactor-integrate cycle, the whole kit and caboodle.

Over time, we grow the must-test list in two ways.

First, we grow it by turning more and more classes into ‘must-tests’. We do that by fixing awkward dependencies, either at the class doing the calling, or the class being called.

Second, we grow it by learning the patterns of refactoring that can make a non-testable become a readily-testable. Each time we get the whole team to perform a new refactoring, we can add classes that would be testable if only we knew that refactoring.

Let’s do an example: many teams have yet to recover from the singleton pattern, so they have classes that depend heavily on global data. Using alternate constructors is a simple ¬†pattern that can solve this problem. An hour of study and one successful attempt, and you’re good to go. Once the team has that pattern, we can add to our must-test list classes that would be readily testable except for their use of globals.

The must-test list starts life as a list you control. Think in terms of adding two classes a week in the beginning. Make the changes in the must-test list at the iteration break, say, during the planning. As the team builds their experience and excitement about TDD, you can gradually hand over management directly to the team.

Coach The Inner Game
Give Their Minds The Right Stance

2 Responses to “Coaching The TDD Inner Game”

  1. meza says:

    Thanks for the post, it gave me an association boost! How does a team proceed with a must-test class? One touches it first writes the test, or whoever touches it covers his own modification?

  2. GeePawHill says:

    I like the idea of the pair that touches it first writes the test, but I can’t always get that from the team. Failing that, I use the cover-your-own-change concept. In early days, as soon as I have even one class under microtest, I project how we did it. — Hill

Leave a Reply

AWSOM Powered