The way I think you should do test driven development

The way I think you should do test driven development is:

1. Think about what behavior you want to introduce
2. Find, or invent, an API where you can express that behavior
3. Write tests that clearly show that behavior
4. Implement the behavior

When deciding on API. Ask yourself what future refactorings can be done with your test being kept unchanged. If your test is likely to break when code is refactored, I would not consider it a good test, perhaps they should be written against another API?

The API can be anywhere in the application.

• If you have a layered application, it can be on those layers.
• If you have complex transformation of models between layers, it can be class level on that transformation code.
• When I do small microservices, I often write tests on the REST-API of the application.

A feature is typically covered with a combination of tests on different API:s.

Write the tests you need, not more and not less.

You should try to avoid mocking frameworks (like Mockito in Java, Jest mocks in Javascript, or similar …). I think you are likely testing implementation, not behavior, if your test has that kind of knowledge. I’m not saying you should never use these tools, just be very careful and aware of what you are doing. And again: “Find, or invent, an API where you can express that behavior”.

If you stalk me on Github you will see that I do not always do these things. The reason for that is that I learn and continuously iterate my way of working, always, and have been doing so for many years.