title: Useful design patterns for unit testing/TDD?
body: <p>Reading <a href="https://stackoverflow.com/questions/67299">this question</a> has helped me solidify some of the problems I've always had with unit-testing, TDD, et al.</p>
  
  <p>Since coming across the TDD approach to development I knew that it was the right path to follow. Reading various tutorials helped me understand how to make a start, but they have always been very simplistic - not really something that one can apply to an active project. The best I've managed is writing tests around small parts of my code - things like libraries, that are used by the main app but aren't integrated in any way. While this has been useful it equates to about 5% of the code-base. There's very little out there on how to go to the next step, to help me get some tests into the main app.</p>
  
  <p>Comments such as "<a href="https://stackoverflow.com/questions/67299#comment-2006643"><em>Most code without unit tests is built with hard dependencies (i.e.'s new's all over the place) or static methods.</em></a>" and "<a href="https://stackoverflow.com/questions/67299#answer-67432"><em>...it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class [...] and so on.</em></a>" have made me realise that the next step is understanding how to de-couple code to make it testable.</p>
  
  <p>What should I be looking at to help me do this? Is there a specific set of design patterns that I need to understand and start to implement which will allow easier testing?</p>