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.