Good post. I would make the small observation that the BeanInitializer is suited for a specific subset of tests, and typically should not be used for the majority of the unit tests in one's code base (not that I think you were suggesting that, I just want to make that clear).

To my mind, the majority of the *unit* tests in one's code base are still going to use plain old Java constructs (indeed, plain old OO constructs) such as constructors and setters to supply dependencies, mock or otherwise, to the unit under test (rather fortuitously, I recently blogged about just this topic). There is no need to involve Spring at this point, because the majority of the classes in a well structured (Di-based) enterprise application are going to have no Spring dependencies at all. Where the BeanInitializer class, and the other support classes in the Spring mock library, provide tangible value is in the realm of *integration* tests; here the Spring support classes, such as the AbstractDependencyInjectionSpringContextTests class, allow one to use Spring to test (well, obviously I guess) the wiring up of all the various interdependent classes in the integration test in a very convenient fashion (and of course the logic too!). The BeanInitializer also has it's place in integration tests for those special cases where one needs to plug in a non-standard implementation of a collaborator to simulate a failure scenario.

The BeanInitializer does have it's place in a small subset of unit tests, specifically those where you absolutely would benefit from using it (haha), or are tied to the framework anyway because one is testing a FactoryBean (for example).

Cheers
Rick