Does TDD's "Obvious Implementation" mean code first, test after?
- by natasky
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.
Also:
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?
