[crdoconnor]

tl;dr the recent studies proved that that you're testing first or last doesn't matter, provided you're frequently flipping between writing a test and writing code.

The author thinks that TDD is preferable because it helps you maintain discipline.

I personally think it's worthwhile besides that because it means you design the API before implementing, meaning it is cheaper to fix API design mistakes. IIRC this aspect wasn't actually tested in the studies (API signatures were given up front).

[AnimalMuppet]

And that's one of the things TDD gives you - as you write the test, you have to use the API. If that's painful or even just awkward, it's telling you something...

[marcosdumay]

Except that it is not real use.

Might be better than nothing, but if you are designing a reusable API, you'll be better using it on some real code.

[crdoconnor]

>Might be better than nothing, but if you are designing a reusable API, you'll be better using it on some real code.

This is generally why I take the top down approach to coding:

1) Write ultra high level test

2) Write code that implements it.

3) In that code if I need something lower level, write the API that I want

4) Write a lower level test that mirrors what I just wrote in real code.

5) Implement the code that passes that test & use it at the higher level.

etc.

[jacques_chester]

> Might be better than nothing, but if you are designing a reusable API, you'll be better using it on some real code.

Agreed, this is why tests should be driven from the outside in.

But at the unit level, tests are often the first contact with production code. Tests are dumb and setting up complicated stateful worlds is painful and tedious.

It becomes easier to simplify the production code to simplify the test code, than to just write the first thing that comes to mind.