> Nice ideas, but I disagree the unit using config files is > not test case. For example I use spring bean factory to > delivery complex beans into my test case.
Although Spring does provide abstract JUnit classes for instantiating Spring objects from a Spring context, what you are describing are not considered unit tests. If you take a look at the unit tests that the Spring samples and library itself they almost exclusively instantiate objects using "new" and wire up collaborators that are mock objects.
This post is really about trying to create true unit tests first. Then if more complex integration tests are needed, those are separate. Michael is trying to foster the idea that unit tests are for testing the proper behavior of a single object and try not to worry whether calling the database, thread library, transaction manager, other objects you write etc actually work, because they should. Or in the case of other objects you write, you'll write unit tests for those.