基于Spring的系统,单元测试是否直接通过mock和new来处理依赖?

基于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和编写用例,十分棘手啊!
问题补充:
有一个头疼的问题。

如果目前花掉很多资源(人力和时间)去补充以前欠缺的单元测试用例,但是如果项目经常有小的升级包和修订,而这些修订是其他程序员去做。如果协调不好,他们对代码进行的修改未及时维护单元测试用例,最终这些用例就不可用了。

即单元测试的维护问题,大型团队经常碰到这样的情况,小迭代,不同的程序员在处理同一模块的代码。

单元测试的维护应该采用怎样的机制呢?

查看全部
wwtyler
wwtyler
2009/02/03 20:31
  • 单元测试
  • 软件测试
  • 点赞
  • 收藏
  • 回答
    私信
满意答案
查看全部

0个回复