My friend and I are relatively new TDD and have a dispute about the "Obvious Implementation" technique (from "TDD By Example" by Kent Beck). My friend says it means that if the implementation is obvious, you should go ahead and write it - before any test for that new behavior. And indeed the book says:

How do you implement simple operations? Just implement them.


Sometimes you are sure you know how to implement an operation. Go ahead.

I think what the author means is you should test first, and then "just implement" it - as opposed to the "Fake It ('Till You Make It)" and other techniques, which require smaller steps in the implementation stage. Also after these quotes the author talks about getting "red bars" (failing tests) when doing "Obvious Implementation" - how can you get a red bar without a test?.

Yet I couldn't find any quote from the book saying "obvious" still means test first.

What do you think? Should we test first or after when the implementation is "obvious" (according to TDD, of course)? Do you know a book or blog post saying just that?

  • 3
    I agree with your interpretation. Test first and "just implement" when the problem is easy enough to solve without iterations. But definitely test first. Sep 14 '11 at 20:46
  • 1
    It is obviously obvious that any code can only be tested after it is written...
    – ThomasX
    Apr 5 '12 at 14:36

I agree with your interpretation - it is still Red Green Refactor, only with the Refactor bit left out ;)

So, write a failing test first, then implement the obvious solution instead of slowly building up a design of "the simplest possible" one.


Do you know a book or blog post saying just that?

I would argue that Beck's book says just that.

He goes on to say

However, by using only Obvious Implementation, you are demanding perfection of yourself. Psychologically, this can be a devastating move. What if what you write isn't really the simplest change that could get the test to pass? What if your partner shows you an even simpler one? You're a failure! Your world crumbles around you! You die. You freeze up.

How can you get the test to pass by writing the code if it doesn't exist before the code does?


Obviously there are no hard and fast rules here, were being agile after all so we can and should adapting as we iterate :)

Partly it will depend on the simple operation, and as you practice TDD more and more you will regularly find stuff you tested badly or actually didn't really test at all, it's all part of the learning curve.

Also don't forget that TDD allows you test the interface and the implementation before committing it to live code.

You may know how to implement something but how often do you write a perfect class/method etc. first time without some tweaks along the way or stepping through the code once or twice and six-months later when you change something you can do so with more confidence and again in the sandbox of the tests.

Of course, tests don't mean you write the code any more correctly first time but your changes are driven by the test and tests become the first client of the code and as tests are very low-cost and more importantly no-risk to change you have more confidence and freedom whilst developing.

If your really trying to get good coverage and higher quality then err on the side of more tests to start with, as you practice TDD more and more you will develop you own sense of the level of coverage you need.


I have learned that for trivial code there should be no unittest at all.

example: If you have a java getter/setter method that maps a method to a local variable a unittest for this would be overkill.

may be this is what the author means with

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.