One of the things I struggle with sometimes is how to write testable code. Especially in an existing system that has lots of established code that is difficult to test. The code may have existing tests, but they are heavy, system tests not quick and speedy unit tests. Eventually, writing more tests in the same style just makes the builds take too long to run, and eventually that one new test may requires several minutes of waiting. Tests that make you wait are not productive, and should not be the norm.
This week I found not one, but two good presentations regarding testable code. Firstly (seen @ the UCOSP blog) was a link to the slides for a presentation done by Misko Hevery & Cory Smith at OOPSLA '09, entitled: "Tutorial: How to Write Hard to Test Code" (PDF Google Docs link). There are quite a few slides, and in addition to illustrating bad practices, there are plenty of examples of writing more testable code as well. Highly recommended, entertaining and educational slides.
The second is a project I already knew about, but never got around to trying. Guice. If you haven't used it (or another Dependency Injection library), I encourage you to watch the youtube video on the main Guice page. The presentation itself has general tips on writing more testable code, and towards the end gets into more advanced examples using Guice. The general principles apply whether or not you use it.
I'll post again with further thoughts once I've had a chance to play around with Guice.