I use TDD with integration tests. At first, my test case verifies a whole feature at a high level, then later when I have the main test case passing, I add more

I use TDD with integration tests. At first, my test case verifies a whole feature at a high level, then later when I have the main test case passing, I add more detailed integration test cases. Once I'm satisfied that the feature works under all the tricky possible edge cases, I merge the feature. I just run my test case to verify that the feature is working. It's way easier than manually testing using a browser or HTTP client to make requests; also it's nice that once I finished testing, I get to keep the test case and it serves to avoid regressions on that feature later. Sometimes I do TDD with unit tests, but only if the specific component is complex enough to warrant a unit test. I don't write unit tests for a simple component where the correctness of the component can easily be inferred from the passing of integration test cases which rely on that component. Trying to cover everything with unit tests from the beginning is a terrible idea and will lead to sub-par architecture. You have to start with tests that cover functionality at a high level first and work your way to the details later; top-down, not bottom-up. The beauty of the integration test is that it forces you to modularize high level logic to make it testable. It forces you to think about the input and output boundaries of the code being tested under integration. Integration testing doesn't mean you need to have a database running during the tests; often you can mock out the database client with a dummy adapter (or an in-memory adapter which works in the same way as the real database for the purpose of testing).