<p>I have been looking at using TDD and implementing proper testing (only just started to learn how much better it makes your life) in any of my projects that I create in the future.  So for the last couple of days I have been floating around on SO trying to learn about how to design your application for testability, but I still seem to be struggling with some of the ideas.  </p>

<p>I have read a lot that you should program <strong>against interfaces</strong> rather than <strong>classes</strong>. The main problem I'm having is, how many interfaces should you create? Should you have one for everything you want to test? or am I reading this wrong?</p>

<p>Another thing is use lots of dependency injection, so you can mock the parts that you are injecting rather than use the real things.  Is this correct? or am I way off here too?</p>

You are right with the Mocking part, if you actually are doing what you said.
As for the interfaces, my personal method of development considering this point is that I first write what my application's main path should look like (using my ideal mock API that does nothing). Then after looking through my Mock implementation and refining it a few times, I start the actual class design. At this stage "know" how I can test each method, and write a test for it, and if for some reason I come across a method I can't easily figure out how to test, it means the method is not good, most likely it has too many responsibilities, and too many intermediary states I can't test, so I break the method up (interface wins over class design here). And keep on trickling down until I have a workable application.