Just for the record: it is flat out impossible to "do the tdd" after the code is finished. This is just a matter of definition.
You can write tests after the code is finished, but that has no relationship to TDD whatsoever. None. Nada. Zip.
In TDD you write a new, failing test. Next you write enough code to pass the test. Then you refactor. This repeats until the code is done, writing and running tests continually. It shapes the way the code is written. It is a technique for making sure you write the right code, and that you do so in an incremental and iterative way.
In ATDD, you have a failing acceptance tests. You take the first failing tests (or the easiest) and use TDD to build the code so that that part of the AT passes. You run the AT after each major step that you've built using TDD. When the AT is all green, you have completed the feature. This helps avoid early stop and also helps avoid gold-plating.
If tests were product, then it would make no difference whether you do them first or last, and redundancy would be silly and worth avoiding.
If tests are rightfully seen as process, then redundancy is "coherence" and not worth avoiding. It helps us move forward.
The biggest problem with TDD is that if you're not doing the process, then the product (tests) don't make sense.
Hate TDD? Then there's a good chance you're not actually doing it.
No comments:
Post a Comment