April 18, 2008

...Learn TDD with Codemanship

Let's Get It Straight, Shall We?

1. Test-driven Development is:

* Write a failing test
* Write the code to pass the test
* Refactor to remove duplication

If you write the code first, that is not TDD (I mean, really! The clue's in the name...)

If you write a stub and then write tests against it, that is Stub-driven Testing, not Test-driven Development.

If you write anything other than the code needed to pass the test, that is not Test-driven Development.

If you don't refactor your code after passing each test, or at least check if any refactoring is needed, before moving on to the next test, then that is Test-driven Design. Test-driven Development = Test-driven Design + Refactoring. No refactoring. No test-driven development.

2. Refactoring

If you "refactor a test to make it pass", that is not refactoring. It is only refactoring if behaviour is preserved, you see. If your test was failing before, and you "refactored" it and now the test passes, then behaviour has evidently not been preserved.

Same goes if you "refactor" your code by adding a new feature. That is not refactoring. If behaviour has been added, then it has not been preserved.

It is also not "refactoring" if you go for hours or days at a time without running your tests. That's just called "hacking". It's not even disciplined enough to be called refuctoring!

3. You are not doing Agile Software Development if your project is currently in a "user acceptance testing phase". Agile projects don't have UAT phases. They get customer feedback throughout development. That's kind of an important distinguishing feature of Agile approaches.


I'm glad we got that sorted. Aren't you?

Posted 10 years, 3 months ago on April 18, 2008