CODEWITHSUNDEEP
javatdd
Vikram
Vikram

Reputation: 33

Test Driven Development in Java - Green Phase

I am new to TDD, in the green phase, after we write the simplest possible code to make the test pass at what point do we go back and write the full implementation? Is it after all the other tests are written or is it during the refactor phase for each test?

Upvotes: 0

Views: 123

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57397

after we write the simplest possible code to make the test pass at what point do we go back and write the full implementation?

Immediately after the green phase, we should execute a refactor phase to bring the current implementation into alignment with our design rules.

But - we shouldn't be expecting to add any unused code branches. We're going after the best code that passes our current suite of tests.

I suggest reviewing Rainsberger's simple design dynamo formulation: with concentration on "improving names" and "removing duplication".

At a more holistic level, I like to consider Ward Cunningham's debt metaphor

if we failed to make our program align with what we then understood to be the proper way to think about our [domain], then we were gonna continually stumble over that disagreement and that would slow us down

Kent Beck offered another motivating idea for this refactoring phase

Make the next change easy, then make the next easy change.

Which is to say, it's okay to refactor the code you have to make the next pair of red/green tasks easy. This, of course, assumes that we have a new test ready to implement as soon as our refactoring is completed.

Note: this is a "full" implementation, in the sense that it clearly an explicitly communicates everything you need to know about the domain for this test, but it's not "full" in the sense of implementing behaviors before we've written tests for those behaviors.

The justification for this approach: one of the reasons that we care about "good design" is that it makes changing the code easier... and changing the code is what we are doing right now. So we want to front load the "making changes easier" bits so that we get that advantage too.

You can, of course, go the other direction: here are 20 tests, and here is a 20 case switch statement that passes all of the tests. Now refactor it all! And that will work, eventually, if you don't run out of stubborn before the end of the exercise.

But it isn't the same process that Beck described in his book.

Upvotes: 1

Related Questions