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

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

About

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:

Guidelines

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

Think

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!

Tests

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

Video

Check the video below with the first episode:

What’s Next?

Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design

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

Credits

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

 

Subscribe

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

Subscribe for new articles

3 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 :)

Leave a Reply

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

Post Navigation