When I was a kid cars didn’t have seat belts in the back seat. We used to fly to and fro all over whenever the car took a turn. These days my kids shriek with horror if we forget to buckle them up and the car starts moving. That’s the mindset.

Some time ago I led a code retreat event. In the first session, I asked the teams to try and build a simulation of Conways’ Game of Life. Immediately they started coding the simulation.

That was odd.

You see, I usually don’t write any code before I have a test ready to run it. What’s the point? I like it when one key press runs all the tests. It makes me feel safe. It’s the same as when I’m getting into my car I wear the seat belt.

When the people at the session were done with coding, they wanted to see if it works. So they wrote a short main and started debugging.

“They wanted to see if it works.” I’m familiar with this. I also used to write code and then just wanted to make sure it works. These days I have a concrete objective in front of me: a test that should pass.

When I started TDDing (Test Driven Dedign/Development) it was strange. I wanted to write code and I felt messing around with the tests was a waste of time. But as I did more and more of it something changed. It made me feel safe.

On the second session of the aforementioned Code Retreat I asked the people to do the same exercise, but this time the test first. They didn’t understand. So I showed them: I take a blank project and write a test. I start with the assert statement. I use in the assert a Class that I still don’t have and also probably a Method that I don’t have. Then I write the code in the test that comes before it. Then I use the IDE to generate the missing classes and methods. Enlightenment!

In the same way that you don’t build a house without scaffolding, you don’t write code without tests. When you start with the tests, you write code that is more testable. When you build a car, you build it so you could have a proper place to anchor the seat belt. It comes together.

(And it works as well with Legacy code. Read Michael Feather’s Working Effectively with Legacy Code. We will also write about it here.)

It is true for a single developer doing unit tests and it is true for QA people running System Tests: Testing and Development comes together.

Dev and Test
sitting in a tree,
K-I-S-S-I-N-G.
First comes learning,
then comes practice
then comes software in a baby carriage… :-O