基于Spring的大型遗留系统的单元测试如何进行呢？
很多遗留代码并没有单元测试。而就算有，这些单元测试其实应该叫做集成测试才是。因为这些测试都是继承的spring框架中的AbstractDependencyInjectionSpringContextTests。这样bean之间的依赖通过加载*-bean-test.xml配置文件来解决。而根据spring框架中AbstractDependencyInjectionSpringContextTests的javadoc中的描述：
Really for integration testing, not unit testing. You should not normally use the Spring container for unit tests: simply populate your POJOs in plain JUnit tests!
这样做不满足真正意义上的单元测试，并且有一个严重缺陷，当大量的用例一并运行时每个用例都是独自的spring容器，运行起来十分缓慢。
但是由于系统十分复杂，耦合性和内聚性也不是处理的太好，如果使用mock（如Jmock）和new的方式来在testcase的setup中处理依赖的话，需要大量的工作。例如某个bean的一个逻辑处理方法可能要依赖多个其他bean的方法。这些bean都需要通过Jmock来模拟，以及处理期望和访问次数。
目前为了降低维护成本，正在推个单元测试，以前基本上没有单元测试，而如果推行单元测试的话，需要大量的资源来构建Mock和编写用例，十分棘手啊！
问题补充：
有一个头疼的问题。
如果目前花掉很多资源（人力和时间）去补充以前欠缺的单元测试用例，但是如果项目经常有小的升级包和修订，而这些修订是其他程序员去做。如果协调不好，他们对代码进行的修改未及时维护单元测试用例，最终这些用例就不可用了。
即单元测试的维护问题，大型团队经常碰到这样的情况，小迭代，不同的程序员在处理同一模块的代码。
单元测试的维护应该采用怎样的机制呢？
这个我觉得就是看项目里面能做决定的人怎么想了，两条路：
1，强制执行，要求所有的人必须做单元测试。
2，撤掉不做了，单元测试不做要求。
我觉得项目有时间的话，有要求品质，第一条路还是可行的，但是强制执行有一点不好就是单元测试的效果不好，质量因人而异。而且还是补的。第二条路呢，其实真正想做单元测试的自己也会做。
你说的和我以前做的项目差不多,大体上也就是这样的解决方案.
单元测试本来就是会消耗大量的资源的,如果你的项目管理的不错,从长远来看,资源的投入是值得的,但是如果项目领导的意思是得过且过的话,我就不发表意见了.