One thing I tell a lot of people who are getting into TDD is to focus on what you want the class's interface (AKA API) to look like. This means that you can sta

One thing I tell a lot of people who are getting into TDD is to focus on what you want the class's interface (AKA API) to look like. This means that you can start with the assertion and work your way backwards. As the author alludes to this doesn't mean building out the whole architecture. For me it means just starting out with a simple case, make it pass, question whether you need to refactor or not and then move onto the next simplest case. A great example of this is Corey Haine's String Calculator https://vimeo.com/7961506 https://vimeo.com/7961506 I agree that TDD is not for everyone but I've found a lot of it is because people are either taking too huge of steps or not spending enough time refactoring their code AND their tests. In the most ideal world you should have a test suite and when something in your application breaks you should only have one test that notifies you of this. This I've found is often very far from the case.