DevTeams.AT

• “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.

Let’s talk about refactoring again: How can you move some code to different value objects using small, safe steps? In this video, I want to show you exactly which refactoring steps I take to extract a factory method, move it to one value object and move some code around it to another value object.

In my last video about “Refactoring Primitive Obsession”, I did all that very quickly to give you an overview about the whole process. I have added a link to that video in the description.

Today I want to show you a small step from this process and explain exactly what I did.