Narrator:

Last Episode, Code Dog tried to discourage Vanilla Pop from trying out TDD. Now let’s see how that affects Vanilla Pop’s ability to experiment with TDD.

 

(Office sounds, keys clattering, VPop continues doing TDD, while plagued by voices of uncertainty (use echoey voices like in a Hitchcock film.)

 

VPop:

How do I do test drive this again? This is kinda hard.

This test library. I think that’s how the assert is written. Or maybe it’s wrong. How do I know the test is correct?

 

Voice:

This test first so so backwards.

 

VPop:

Ok. Write the product code now. Huh. I’ve spent so much time writing one test. I really want to spend the rest of the day writing product code. But that’s not TDD right? But what is TDD? What is a correct test? What is life? I feel so uncomfortable! What is happening?

 

Voice:

why not write more product code? I mean who writes their test first anyways?

 

VPop:

OK, OK. Focus. (Strained) Need to focus. Must focus. Write only a stub for the product code… then run …. the … test. Not going to make it.

VPop: Uhhn! Click … run … on … test … runner. Did it! Red bar.

 

Voice:

Really? How is this a good use of your time? You’re paid too much to write tests.

 

VPop:

Huh. OK, write a bit of product code. (tap, tap) Done. A hardcoded solution that will make the test pass.

 

Voice:

why not keep writing product code? You don’t need to run the test again. You KNOW it’s going to pass.

 

VPop:

Must … run … test. (click) Huh? I got a red bar!??

 

Voice:

See? You didn’t even get that stupid test working yet. You need to abandon this madness!

 

VPop:

Wait a minute! I was linking the test to the wrong class. Stupid mistake. OK. Let’s run the test again. Pass! Green bar!

 

Voice:

No one else in the company does it this way. Is this really worth it? Sooo much time spent writing tests.

 

VPop:

Well, I guess it was a good idea. I mean otherwise, I’d have spent a lot of time coding and I wasn’t building the product code. The test was so simple and the first bit of product code was so simple….. It had to be a big misunderstanding. I guess TDD helped me discover that now rather than an hour or so later. So maybe I should keep going and see how this TDD idea will turn out. I hope Code Dog doesn’t come by for a bit and distract me.

 

Narrator:

there are two kinds of challenges happening here: some that’s avoidable and some that is not. What isn’t avoidable is the “retraining” of the brain. When following familiar habits, the pre-frontal cortex is not very active. Because the situation is familiar, your brain accepts that the act of development means spending a lot of time using the debugger to manually unit test code. Because Vanilla Pop is attempting to establish a new habit, his frontal cortex is light up like a light bulb, busy and working hard. This gives Vanilla Pop the impression that his effort to do the new TDD practice is extremely hard. In these cases, the clock time for the two ways of doing this work could be the same or even, but because the prefrontal cortex is heavily involved, no matter what Vanilla Pop *feels* he spends a LOT more effort doing something new TDD rather than following his existing habits. So the act of stopping yourself from doing write the product code first takes mental effort by itself.

 

The effort of learning a new habit is unavoidable. We just need to keep at it and eventually the frontal cortex will shift to the lower energy state of “auto pilot.” What is avoidable is the effort to deal with Fear Uncertainty and Dismay. FUD. If Code Dog hadn’t told Vanilla Pop all of those negative things and if the management had been clear in supporting TDD, that would have reduced the amount of negative mental chatter Vanilla Pop had to fight. So it’s important that developers have clear support when learning TDD in order to propel them along during this retraining effort.

 

Next episode we hear from the Architect about TDD: (Sound bite.)