Key to OO design

I use to agonize how to organize code into classes, that is, how granular to make classes, should this class know how to entirely do X operation, what variables to expose and how to expose them, try to see how various class design patterns might fit (or not). 

In the last 3 years, class design has suddenly become a lot easier by focusing on test-driven design, how to make sure my classes can be tested in unit tests.  Everyone wants a well-designed class with well-designed methods to consume, and a well-designed class is also easier to test and verify as working properly.  But does a class that is designed with being testable in mind make for a well-designed class?  In my experience, strikingly yes.

If so, what supports test-driven design?  Dependency injection like implemented by the Spring framework supports test-driven design because together with interface-focused design, mock implementations can be substituted for real implementations in unit tests.  This alternative way of looking at how to "compose" together classes to do something useful has revolutionized my class design habits, buried bad practices and further made me a believer in test-driven design/development.  In general, I still don't write automated test cases first but I do sometimes (a third of the time?) begin with them now.

Notes on early TSS.NET Unit Testing article

• Article
• "A test fixture is a class that contains a series of test methods ... This grouping is important for two main reasons: one, it creates a subset of tests that can be run as a group, separate from other groups of tests, and two, it provides a level of granularity for controlling the lifecycle and context of a test."
• For database code, article suggests using stored procedures to initialize database for a unit test and calling these stored procedures in SetUp and TearDown.  Also, more specific stored procedures to create additional data for specific tests.  More ideas:  Get Test Infected with NUnit: Unit Test Your .NET Data Access Layer 
• a mock object will have the same interface as the "real" object.  The implementation of the mock object should track usage, allowing you to determine if the right calls were made (by the tested code), and expose any methods/properties that test code might use to evaluate results.  Rather than implement yourself, can use a dynamic mock object library such as NMock
• Nester helps verify code coverage by unit testing:  "involves modification of programs to see if existing tests can distinguish the original program from the modified program" (mutation testing)
• So that test code doesn't force breaking encapsulation of the tested code, have tests reside in same assembly and namespace as code being tested.  Then non-public methods/properties that need to be accessed by test code can be marked with internal modifier