DevTeams.AT

“Why are good people stuck in bad jobs?”

I read that on a whiteboard somewhere and immediately regretted that I missed that discussion.

Now, I decided to start a short video series around the topic.

• “Why do you want me to write wong code?”
• “Why is Red so important?”
• When do you stop to fake?

In the last 7 videos, I answered these and other questions about the “Red” and “Green” phases of the test-driven development cycle.

Today I want to do a short recap.

I have been at the DevOne Conference Linz this year, and… It’s been a blast.

I have already been at some very well organized conferences, but this one was the best so far. The program, the food, the organization: Everything was very close to perfect.

Here’s what happened, my impressions and some opinions…

When you do TDD, “fake implementations” or “wrong code” are OK, as long as they pass all the tests you have so far.

But when do you stop to fake? When do you start writing “real code”?

There’s a rule that helps you decide: The “Specific / Generic Rule”.

“My current test does not test the final version of the feature yet. Should I change the test or add a new test?”

To answer this question, I want to talk about a concept called “Triangulation”.

All the code is tested. All tests are green. But you are at a point where you cannot possibly continue.

To finish the current feature, you would have to change all your code, breaking several tests. You wrote yourself into a corner.

What do you do now?

How do you know which test to write next? How do you make sure you make progress towards your goal, that is, towards implementing a feature that is useful to your customers?

The pair of programmers wrote a test. They ran it, and it was “green”. They started to write the next test.

I said: “Wait, stop it! Your test was green!” They were like: “So what?”

Today I want to talk about why “red” is so important in test driven development - Why you must see a test fail first.

“Why do you want me to write wong code?” an attendee asked me in the break of one of my test driven development trainings.

At first, I did not understand the question: “No, in an ideal world, I only want you to write correct code! That’s why I teach these trainings.”

Then he explained…

One of the first things you must learn when starting with test driven development - or TDD - is how to write a good, “red” test and how to make this test green.

And this is already harder than you might think.

A good red test constrains the implementation you are about to write in just the right way - not too little and not too much. It takes you one step closer to your overall design goal; that might still be pretty far away. It enables you to write an implementation that will allow you to make the next test red again.

To make the test green, you must write the smallest possible implementation that will pass the test. And most people I know were surprised - schocked! - how small is sometimes necessary.