TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.
Support independent publishing: Buy this e-book on Lulu.

TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)


TDD as if you meant it is a very strict way of writing code in a Test Driven Development approach. One needs to follow the rules below:


In the first episode the main focus in to respect a few guidelines:

  1. Guideline 1: Always start with outputs when doing an analysis
  2. Guideline 2: Behavior Slicing
  3. Guideline 3: SIMPLIFY!
  4. Guideline 4: Introduce only one notion (domain concept) at a time, one per test
  5. Guideline 5: The rule of three “only extract duplication when spotted at least three times”
  6. Guideline 6: Triangulation


The most important thing with TDD is to think before starting to code. So I introduced this step and I am using the cycle

Think -> Red -> Green -> Refactor

We do need analysis before writing code and before using Test Driven Development!


Based on these guidelines I started writing some tests, while simplifying to the maximum the problem.

My first test is about the simplest Tic Tac Toe game: X always wins on a one by one board


Then I started triangulating on the notion of winning


Check the video below with the first episode:

What’s Next?

Check the next episode on TDD as if you Meant it here:

On the same page you can find more ideas on Evolutionary Design.


Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It

Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.

Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It



If you want to receive an email when I write a new article, subscribe here:

Subscribe for new articles

7 thoughts on “TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

  1. Nice series, Adi 🙂 Looking forward to the next episode. By the way, one of the “rules” of TDD is to write the minimum amount of production code to make your failing test pass. In this sense how to justify the “Nobody won” else-block? After all it isn’t actually exercised. Cheers :)

      1. Thanks for the comment Pawel! You are right, ‘that area is not tested. But when I will add a focused test on the other branch and extract the method, then the resulted method will be tested as it should.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for new articles