Integration tests are top-down and focus on checking that the system under test behaves as expected. They usually require elaborate setup and configuration and

Integration tests are top-down and focus on checking that the system under test behaves as expected. They usually require elaborate setup and configuration and can - depending on the system - take considerable effort to start and run. The idea behind TDD focuses on a bottom-up approach instead - if all the parts behave as expected, it is reasonable to assume that the entire system will. TDD was also intended as a tool to help identify problems with design early (e.g. too many dependencies, tight coupling, too many responsibilities, reduce/eliminate side effects, etc.), allowing for rapid feedback (tests should execute quickly and require little to no setup). Both approaches have different goals in mind and serve a different purpose. Ideally you always have both - run unit tests after each code change (i.e. often), run integration tests after each added or changed behaviour (e.g. daily or as part of an acceptance test process). Starting with integration tests much work up-front and adding unit tests after the fact can introduce considerable overhead for questionable gains.