Visit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.

Vanilla Pop: And see? You just write a bit of test before writing product code and everything will be peachy.

Joe: I don’t know. It’s kinda mind bending to work backwards like this.

 

Vanilla: but you’re good enough to do it right?

Joe: of course I am! I’ve got it from here!

 

Vanilla: (sounding uncertain) Well, I thought we’d continue Pair programming.

Joe: would you believe I find you incredibly intimidating? And that I need to work alone to satisfy my self esteem?

 

Vanilla: well OK. When you put it that way.

(Time passing music with typing sound. Then end of day, a light switch clicks and the door closes.)

Next day

 

Vanilla: Let’s take a look at those tests.

Joe: here you go! You’re going to love it. I made some adjustments.

 

Vanilla: Huh? When I click the run tests button, they stop after a bit and

Joe: (proudly) a dialog pops up!

 

Vanilla: uhhh

Joe: Yes! It’s the ol’ Dialogue to ask the user what crazy value to pass into the tests trick. I was able to replaced four of your tests with just this one.

 

Vanilla: ah… But now I have to interact and before—

Joe: Brilliant isn’t it! And if you need to debug, it’s all there ready to go!

 

Vanilla: but Joe, I don’t want to interact with the micro tests. Someday we’ll have thousands and it’ll take forever if We need to interact. With one click, Joe, we want all the micro tests to run.

 

Joe: (heart broken) Oh! I’ve got it. Let me handle this.

(Time passing)

 

Vanilla: why is the Test runner reporting fewer tests today than yesterday?

Joe: would you believe that the test started failing for some reason, so I disabled it?

 

Vanilla: hold on! You’re saying that day by day I’m adding more tests and the count goes up and then your first few days on the job, you’re making the number go down?

 

Joe: well yeah. Your test stopped working after my code changes.

 

Vanilla: yeah? Well you’re supposed to maintain the tests that are checked in or we’ll get no where.

Joe: but you designed it to be too inflexible. If you had agreed to use the ol’ dialogue to get the user’s input trick, like I had it—

 

Vanilla: But Joe, each single micro test is designed to test one scenario and only one scenario. This keeps the tests simple, easy to understand, and easy to maintain.

Joe: So what would you have me do when a test fails? Go for the Dialogue Pop, Dialogues are the shizzel!

 

Vanilla: Maintian the Test Joe.

Joe: how do I know which is wrong? The test of my code?

 

Vanilla: the test did its job by notifying you that something is up. At that point, you need to look into the matter and make a determination: are you creating a regression or does the test need to be updated.

 

Narrator: Vanilla Pop is faced with getting team member to learn TDD. The mis step occurs when he failed to get Joe to continue pair programming. Developers are trained by the education system to “go it alone.” Add to that many developers rather spend hours alone struggling with a computer rather than face conflict with others. It’s how we are wired. It’s a characteristic that’s helpful to learn programming. We suffer alone trying to get the computer to do what we want, and stick at it until we are good enough to successfully deliver projects.

 

But there are better ways. We are no longer in school and part of the value of working at a company is, well company of other skilled developers. The more developers work together, side by side, the faster the skills of one are socialized into the other, and alignment around following new processes such as TDD happens orders of magnitude more quickly. Pair Programming is the key secret sauce to learning technical practices the right way. Otherwise, the feedback loop is slower as shown between Vanilla Pop and Junior Joe.

 

Next episode, Code Dog gets mixed up in a code coverage scandal.