单元测试的噩梦

Somerset的单元测试是自动进行的吗?

原因的原因的原因就不是原因。
能把原因追究到“市场又和政策政治相关”，只怕
是没找到点。

简单说，有测试比没测试效率高。尤其是在工期紧的时候，花20分钟写测试或者花两小时debug，这种事情是很常见的。

建议:
1。每个测试方法都要尽量具有独立性
2。每个测试方法都要尽量的简单

上面可以说是单元测试公认的原则，但实际应用中，还是常常被忘却了

不妨借签一下Apache项目中的测试用例，你可以从它的CVS服务器上当下来。

小规模的项目和试验性项目才可能搞搞这么频繁的单元测试，大的项目从项目规模，时间上都不太现实

恰恰相反，小项目和实验性项目没有测试也可能幸运存活，大项目如果没有大量自动化单元测试的保障，三个月之后就会寸步难行，因为任何新增特性都无法确保不破坏现有的东西。

晚上比较适合做整合测试。对于日构建的单元测试，一定要在下班前完成才能checkin cvs，尽量不要拖到第2天。

楼主对单元测试显示理解有偏颇。
　
（1）“里边夹杂了太多的业务逻辑”，单元测试怎么能夹杂业务逻辑呢？！！！单元测试代码是用来测试业务逻辑的，楼主怎么还加入什么业务逻辑。单元测试应该尽量的简单和独立，简单性和独立性是单元测试代码的原则。细粒度是实现单元测试代码简单性和独立性的方法。
　
单元测试的目的是为了让我们今后维护时能更快的定位BUG，所以简单独立测试代码更易读、更利于这个目的。如果阅读一个单元测试代码要超过十分钟，我觉得这个单元测试就算是失败的。
　
（2）“创建一个新的测试要做很多初始化的工作”，其根本原因是在于楼主的单元测试做法有误，"单元测试粒度过大，造成测试类过于臃肿"，“大量依赖外界环境，如数据库”。
千万不要写类似这样的单元测试代码：[输入一个数据，然后数据经过业务逻辑处理，而经过Hibernate进入数据库，然后单元测试从数据库读出数据来看看数据是否正确]，这样的写单元测试的思路是根本错误的。试想，如果运行测试时出错，你就很难从如此庞大混杂的代码中定位问题是出在业务逻辑层面、还是中间层、还是数据存储层。
　
千万不要写上面那种一杆子捅到底的测试代码。你应该这样，针对[数据经过业务逻辑的处理]来写一个单元测试。只针对最复杂和最核心的逻辑来写单元测试，减少了单元测试代码的数量，也就减少了对测试代码本身的维护量。有一些不应该由单元测试来做的工作，还是留到集成测试和测试员的beta版测试吧。
　
（3）单元测试要尽量做到环境无关性。比如测试EJB的单元测试，运行它并不需要启动Weblogic等EJB容器才能测试的，因为我们主要是测试它的业务逻辑，业务逻辑和weblogic容器是无关的。要实现这个目的，也就要求我们在写代码时要把业务逻辑写得更单纯，让它和容器相关的代码分离开来。
　
数据库也是一个常见的环境无关性问题，我们必须让单元测试脱离数据库（也就是脱离环境）而能运行。解决的方法是：我们可以写一个假(mock)的数据库，这是很简单的：一个类加几个List变量就可以模拟库和表了。

如果你维护过大项目，你就不会说这样的话了。
（1）没有单元测试，你无法重构，因为你不知道你的修改是否正确。
（2）没有单元测试，你出错后，你无法最快的定位BUG所在。并且在修改BUG后，你无法得知自己的修改是否影响到了其他模块。
（3）没有单元测试，你很难进行需求的修改。

总之一句话：没有单元测试，就很难对代码做修改。所以说小项目可以没有单元测试代码，但大项目一定要有，不然没法维护。另外，单元测试代码逻辑简单，写起来并不是想想中的那样耗时。

说得真简单，那写个sample来看看？

这个结论不知道如何得来。做了大量的自动化UT能解决问题？ 那你的UT的用途是什么？测试类方法？测试业务逻辑？测试需求？ 你开发的系统类型是什么？MIS？那又如何UT？