[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.