TDD and Real Options

A couple of days ago I watched the fantastic “TDD as if you really meant it” session by Keith Braithwaite on Infoq. I highly recommend it even if you are not a developer ( writer of code ).

I love the simplicity of the process that Keith tells the session attendees to adopt. It is a great exercise in emergent design that highlights how easily developers make assumption about the design rather than let it emerge.

The only thing I questioned was Keith’s suggestion that the developers start “anywhere”. As Keith said this my immediate response was “Start with the ouputs”. I commented on the InfoQ article as such.

I got the impression that a number of the people in the session started with the inputs. They soon ran into problems and started making assumptions about the design. This is exactly the opposite of the Feature Injection process which starts with the outputs. A colleague ( developer ) and I started going through the Tic-Tac-Toe exercise using pseudo-code. (I’m hoping to complete the exercise using C#).

As we worked through the exercise starting from the outcome ( Game Over ) and working into the functions ( isWon, isStaleMate ) generating Mocks as we went along, we suffered from none of the problems that the people in the session encountered. We had none of the desire to make assumptions about the design. More importantly, we quickly encountered the fundamental domain questions about Tic-Tac-Toe ( 3×3 Grid? 4×4 grid? 3 dimensional grid? ). How do we test to make sure the isWon works properly. Issues about inputs were not even discussed. Issues about display were not discussed. We had lots of options. We drove right into the riskiest part of the development from a domain perspective.

Previously I have never commented on TDD but it seems to me that TDD should also start with the outputs and work to the inputs. In effect, Feature Injection, should be injected into TDD.

I’m waiting for the flames!

Disclaimer – I assume someone else has already said this but I just am not aware of it.

I will post the code when I do it in C#

Pseudo Code: Code in red

Test 1 – isFinished is TRUE

iSFinished() return True

Test 2 – isFinished returns FALSE

isFinished() return game.Finished()

Create mock game.isFinished returns False

Test 1 Fails. Refactor test 1 to use Mock game.isFinished returns True

Test 3 – game.isFinished is TRUE

game.isFinished() return TRUE

Test 4 – game.isFinished is FALSE ( GIVEN NOT isStaleMate AND NOT isWon WHEN game.IsFinished THEN FALSE )

gameisFinished()

if game.isWon() || game.staleMate() then

    return TRUE

else

    return FALSE

2 Mocks game.isWon() returns FALSE and game.isStaleMate() returns FALSE

Test 5 – game.isFinished is TRUE, isStaleMate ( GIVEN isStaleMate WHEN game.IsFinished THEN TRUE )

2 Mocks game.isWon() returns FALSE and game.isStaleMate() returns TRUE

Test 6 – game.isFinished is TRUE, isWon ( GIVEN isWon WHEN game.IsFinished THEN TRUE )

2 Mocks game.isWon() returns TRUE and game.isStaleMate() returns FALSE

Test 7 – Test 7 – game isFinished is TRUE, isWon and isStaleMate ( GIVEN isWon and isStalemate WHEN game.IsFinished THEN throw exception )

2 Mocks game.isWon() returns TRUE and game.isStaleMate() returns TRUE

gameisFinished()

if game.isWon() || game.staleMate() then

    return TRUE

elseif NOT(game.isWon() )&&NOT(game.staleMate()) then

    return FALSE

else

raise exception (“Its broken because it should be possible to win and be in stalemate”)

The coding finishes when all the mocks are all implemented.

Coding to be continued…

Note that the GIVEN WHEN THEN calls out the Mocks to use. Mocks were the inspiration for the pattern.

Notes:

 

Tic Tac Toe ( Winning )
1	1			1			1
2	1				1			1
3	1					1
4		1		1
5		1			1		1	1
6		1				1
7			1	1
8			1		1			1
9			1			1	1

Display

 

1	2	3
4	5	6
7	8	9