单元测试的噩梦

当项目进展到一定程度，也会产生出大量的单元测试代码。而且这些单元测试代码也被不断的增加、修改和删除。渐渐单元测试代码也变得难以维护了，里边夹杂了太多的业务逻辑。创建一个新的测试要做很多初始化的工作，很难在ide里直接运行所有测试，很难单独运行某项测试，运行所有的单元测试要比较长的时间......

我想了下，造成这种现象的原因有以下几种：
1.未及时对单元测试进行重构，删除不必要的测试，合并类似的测试。
2.单元测试粒度过大，造成测试类过于臃肿。应该把大粒度的测试抽出来单独作为功能测试运行。
3.大量依赖外界环境，如数据库。应使用mock object解除依赖关系。


和大家一起讨论一下。

我想根本的原因还是你们没有频繁地运行测试。要是每过10分钟跑一遍全部测试，你们早该受不了了，也不至于把问题堆积下来。

不用十分钟，一分钟我就受不了了。
是make it work这样的想法出现太多次了，总是想找时间再来好好的refactor。

不过还是希望能找到一种途径能够逐渐的顺其自然地进行大规模重构。
refactor那本书对大规模重构讲得还是比较少。

应当专门找出时间来重构，频繁的进行测试。而且，保持测试的独立性也是必不可少的。

还有，最好可以保持每天的构建，这样的效果不错哦。

这个也是我们遇到的问题，和楼主一样，头都大了。

你没懂我的意思。我是说，你应该每隔10分钟就把所有测试跑一遍，确保你当下的工作是在正确的路上。这时如果你发现某个测试让你难受了，就马上重构它，这样每次重构都是小规模的，测试质量逐渐就变好了。如果你的测试是每过半天、一天才跑一遍，当然偷懒的心理会占上风，而且重构的规模也会变大变困难。

我不太欣赏“大规模重构”这种话。重构就是很日常的事，每过10分钟20分钟就跑一遍测试，做一点重构，这样你的代码始终都在好的状态，根本就不需要大规模重构。如果你发现需要做大规模重构，说明你的步伐本身就已经出问题了。

是这样的，我们的步伐是有些问题，所以想找一个好的途径来解决。目前能做的只能是新加的东西能改善一点就改善一点，但是如果不大规模的重构的话是很难从根本上解决目前测试运行缓慢的问题。

make it work?
如果之前的工作太多，那么就应该用monk对象替代掉真实的，可以分成若干个测试。当然这个方法有很多前提条件。如果给出这个monk也成为难事了，那么应该考虑重构你的test代码。

而且，在准备修改一些功能或者结构的时候，应该先给出test，然后再去动手写。最后让这些test通过。

没搞清楚多种实践间的相互支持的关系，
不能坚守敏捷开发的纪律,
单纯提“make it work”，
只能是放纵自己时用的一块遮羞布。

在去读读《解析极限编程----拥抱变化》吧。

首先问自己几个问题
1. 测试是不是程序员自己写的
2. 是不是用的Test First
3. 如果是unit test, 是不是 method by method写的
4. 有没有区分什么是unit, integration test, 什么是functional test.

另外， mock object 用 domain 建模不错，用steve freeman 的话讲， 可以finding interface. 不过根数据库的交互，还是用dbunit做integration test好。 关于 mock 的一些资源可以看 http://emarket.blogdriver.com/emarket/449034.html

如果Test 不能再IDE里面运行 还是不要用IDE了, 开了IDE就是为了写Test,  结果还运行不了.....

以下几点想法供楼主参考

1、测试的粒度和范围：
    测试应该尽量减少测试的范围，不该一个测试什么都管。一般我们都是一个服务一个测试，但如果这个服务过大的话，我们也经常分而治之，这样加快测试程序的效率。不过，这种情况下，通常发现很多东西属于功能测试范围。
  
   单元测试本身并没有打算把所有的测试都做完，许多测试本身属于压力测试和功能测试。 大范围的数据初始化可能说明一点：测试过头了。

2、难以测试
   如你所说，我们在做Struts的时候，发现表现层根本无法测试，后来发现了mocket request之类的东西，还是做到了测试。按道理说，Action这里面的代码量少之又少，牛人言：属于功能测试范畴。

3、环境以及初始化
   在我们的开发过程中，无论IDE还是ANT，都是能运行单元测试的。我们和业务代码一样，频繁的重用单元测试的代码。