The basic principle of TDD is that you write the test first and then write the code required to make that test pass. There’s more to it though if you expect to see all the benefits. If you drive your development from integration tests instead of atomic tests, you’ll wind up with highly coupled code again and because it grows gradually without up-front planning, it’s often harder to understand.

If however, you drive your development by atomic tests, you are very strongly encouraged to decouple your code whenever possible because mocking out dependencies is so annoying and time consuming (plus the more you have to mock, the more brittle your tests tend to be).

Integration tests are essentially to success – they make sure that your atomic tests are testing the right things and that the end result you get is what you actually want. It’s extremely beneficial to write acceptance and integration tests before you start writing atomic tests (see: Acceptance Test Driven Development). The design phase however has to be done with atomic tests if you want to encourage decoupling of code.

It’s definitely enlightening to look back at code that has been created using integration testing instead of atomic testing and see how much more complex it looks.