Developing Software Together

TDD: Red-Green Part 7: Specific / Generic


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”.


TDD: Red-Green Part 6: Triangulation


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


TDD: Red-Green Part 5: Into a Corner


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?


TDD: Red-Green Part 4: List of Goals


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?


TDD: Red-Green Part 3: Why Red


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.


TDD: Red-Green Part 2: Wrong Code


“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…


Red-Green Part 1: Introduction


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.


Refactoring: Move to Value Object


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.


Red, Green, ... Part 0: All Posts


I sometimes teach test-driven development, or TDD, to developers who have never done it before. And at the beginning of those trainings, most of them struggle a lot with the first two steps of the “Red, Green, Refactor” cycle: How to write a failing test correctly and how to make this test pass correctly.

In this series of blog posts and videos, I want to focus on those first two steps: “Red” and “Green”. You can find all the parts of the series here:


Refactoring: Primitive Obsession


“How did you refactor that?”

After my video about “Primitive Obsession”, a viwer asked me on Twitter how exaclty I refactored the code towards the final result.

Which steps did I take? Which transformations did I perform in the code?

In this video, I want to show you how I would refactor this piece of code to get rid of the primitive obsession.