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.

Converting legacy Java project to Mavenized project

For the majority of Eclipse-based projects, the most time-consuming part of converting to Maven is (a) determining which JAR files are actually used (compile and run-time), (b) determining their Maven GAV coordinates, (c) hosting the JAR files that are not stored in any public repositories.  Here are the steps I am currently following:

1. Some currently included JAR files may not actually be used.  These steps weed out those extraneous JAR files
2. From the existing files in the lib directory, determine which of them are actually needed by eyeballing.  You should have a pretty good idea of the major dependencies (e.g. core Spring, web service libraries).  Add these dependencies to POM; get GAV coordinates using something like determine-maven-dependencies-tool, a custom Groovy script I wrote that is now on Google Code
3. What are remaining compilation errors?  Look for the specific JARs in which missing classes live, using a tool like JarScan). Add these dependencies
4. What to do about JARs that are not found in publicly available Maven repositories?  
1. If found in non-standard repository, add repository to your Nexus server
2. If not found in any repository, upload JAR to your own Nexus server.  
1. Is it one already in your Nexus repository?  Verify by calculating sha1 hash of JAR contents:  File Checksum Integrity Verifier utility
2. What GAV coordinates to use for these unique JARs?  This is a question I am still seeking convention/guidance on.