Test Driven Spring, Games and Setter Based Injection

ConstructorInitialization "Constructor Initialization is my first choice. There are cases when it's difficult to set things up this way and I do occasionally prefer setter initialization, but most of the time constructor initialization is the best bet...A large list of construction parameters, like any large parameter list, is a CodeSmell. Usually when I see these I find that many of the parameters are DataClumps and should be replaced by their own object. Having said that it's not unusual for constructor methods to have more parameters than other methods - but they are a good place to spot data clumps."

This is a summary of a previous article "Inversion of Control Containers and the Dependency Injection pattern" especially Constructor versus Setter Injection. Constructor based injection plus autowiring seems to work well with preventing errors in configuring dependencies (also mentions using JFig and Commons Configuration to implement auto-reloading of Spring configuration, although it's unclear exactly how to do this).

Unit Testing Hibernate Mapping Configurations Unit Testing Hibernate Mapping Configurations "...developers don't always remember that the mapping files that drive Hibernate's behavior are as much a part of the program as the Java code. These files can contain defects, behave unexpectedly, and break when you change other parts of your system. In this article, I will show how you can use unit testing to assess the correctness of your Hibernate configuration. The article is a step-by-step approach that also explains some of the more common difficulties you may encounter while using Hibernate."

This is a reminder that Spring configuration can be a source of errors/bugs as much as any other part of a program. In the same way you would test drive another part of the system you should test drive Spring configuration. The helps ensure rapid feedback - instead of waiting for deployment to see if you missed any dependencies. This seems like the approach taken in another IoC framework, Yan (also, Nuts vs Anemic Domain Model).

And for people who think that pair programming isn't a game check out, The Pair Programming TDD Game. Mentions the virtuous cycle: red for a broken test, green for the code passing and grey for refactor (should be blue). And of course, you can make development a game and work at a game company - the fun squared.