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.

 

(A knock. Architect says “enter”. Door closes)

Architect: I called you to my office to discuss your project.

 

VPop: Yeah?. Is something wrong?

 

Architect: I was reviewing the code you checked in and I have some concerns. Do you have a project number for these code changes?

 

VPop: Yeah. of course I do. It’s written in the checkin comments.

 

Architect: But… you made code changes here and here, and here and here.

Oh! And what have we here? Some new files: AggregationTest, LoggerTest, and RaterTest. Nice! You’re adding test automation. I like that, but come on. The functionality for project 555439 is really only in Rater. Did you read this comment block? Wow. Such a beautiful comment block! It expresses in natural language what the code does.

 

Pop: Sure enough. But—

 

Architect: You only needed to change one file, but you changed three and added three tests. Mind you, I’m not complaining about the tests. But changing this other code…

Pop: yeah well—

Architect:More changes mean more bugs after all. I mean why change Logger.

 

Pop: When Rater executes, it uses Logger, and logger opens network connections and you know what? That slows down my microtests by about a million percent.

Architect: seriously?

 

Pop: I’m not kidding. Normally the logger talks to a service. So it waits for a network timeout thag makes the test take over a minute instead of a millisecond. So I refactored the Logger to use a memory buffer instead. And I did it with TDD so I wrote a LoggerTest first.

 

Architect: Huh! You don’t say… and this other class?

 

Pop: it needed refactoring—

 

Architect: refactoring?

 

Pop: yeah. It’s where you change the design of the code without changing its behavior. I had to touch those other classes to isolate Rater from doing things that micro tests are forbidden from doing, like writing to the database, file system, or network.

 

Architect: so hold on! Instead of writing maybe one system test, you made extra code changes to have these micro tests?

 

VPop: These micro tests run really fast and you know what? When they detect a failure, did you know they practically point at where the bug is?

 

Architect: but one system test covers what takes thousands of micro tests. I don’t want these… I want to test the system (see quote about the system)!

 

Narrator:

Biases play a large role in the failure of adopting TDD. Architects are used to working with a big picture and have a bias toward big picture testing. VPop needs to not give up and realize it will take some time and real life experience to change the architects bias. A good place to start is to send the architect links to Agile Thoughts episodes 1 through 8, the Test Pyramid series. This type of big picture view will match with an architect’s big picture bias.

 

Attributions:

Sounds from the following FreeSound.org contributors were used in this podcast: amholma