Writing Unit Tests Later

Question

I know that TDD style is writing the test first, see it fails then go and make it green, which is good stuff. Sometimes it really works for me.

However especially when I was experimenting with some stuff (i.e. not sure about the design, not sure if it's going to work) or frantically writing code, I don't want to write unit tests, it breaks my flow.

I tend to write unit tests later on and especially just before stuff getting too complicated. Also there is another problem writing them later is generally more boring.

I'm not quite sure if this is a good approach (definitely not the best).

What do you think? Do you code write your unit tests later? Or how do you deal this flow problem or experimental design / code stage.

Answer 1

What I've learned is that there is no experimental code, at least not working in production environments and/or tight deadlines. Experiments are generally carried out until something "works" at which point that becomes the production code.

The other side of this is that TDD from the start will result in better design of your code. You'll be thinking more about it, reworking it, refactoring it more frequently than if you write the tests after the fact.

Answer 2

I've written tests after the fact. Better late then never. They are always worth having.

However, I have to say, the first time I wrote them before writing the tested code, it was extremely satisfying. No more fiddling around with manual testing. I was surprised just how good it felt.

Also, I tend to write unit tests before refactoring legacy code - which, almost by definition, means that I'm writing tests to test code that's already written. Provides a security blanket that makes me more comfortable with getting into big blocks of code written by others.