On Test Driven Development BUT in REVERSE

Question

I appreciate TDD and think it indispensable but always write my tests ONLY after I write my source code then refactor accordingly. I can never bring myself to write the test first then the source to pass the test. So I always reverse the process. Is this a bad practice on my part? What are the disadvantages of doing it in reverse like me?

Answer 1

If you don't write your tests first then it's arguably not TDD. With TDD you normally write the test, watch it fail, then implement to make it pass.

The advantages over your workflow are:

• Your tests can fail! It's all too easy to create a test that simply cannot fail. And as Eric points out, if you don't write the test first, and watch it fail, how do you know the test is actually testing the functionality you just implemented?
• Your code is definately testable. Although I'm sure you follow testable techniques, test first development ensures that the code is definately testable as otherwise you wouldn't have written the code :-)
• Turns your solutions "upside-down". Debatable one this but TDD makes you think about "what you need" rather than "implementation details". By producing tests first you piece together your general architecture/class structure in your tests, then you get onto the implementation details.

You can mitigate the risks of all of those points, so it's down to you whether you want to keep going the way you are or switch to test first.

Answer 2

If you write the tests afterwards, do they really drive the development/design? I wouldn't think so.

To expand on Steven Robbins' answer: If your test does not fail before you make it pass, how do you know it is testing the right thing?