对junit的一点体会

任何时候都不能写出完美的测试程序,只有不断地重构,不断地吸取经验,不断地写测试,是一个循环!
努力吧!!

要么用mock objects
要么用Cactus.

呵呵，看看《JUnit in action》吧。
JUnit 的作者 Erich Gamma说的好，在你没有看过这本书之前，不要对你的j2ee应用做单元测试！

最近正在努力的啃
JUnit in action

目前我都是首选mock objects，
不过mock objects 的构造过程比较麻烦，特别是数据库类的，很容易导致构建环境的代价太高。
但是优点也是非常明显的，使用mock objects的test case最纯，速度上也最快。（所谓最纯，一个test case它要关心的东西都在当前这个test case类中，只要保证该test case逻辑的清晰和足够简单，那么我认为是最佳的test case方案）

对于写test case复杂的问题，我的处理原则是，一旦发现编写test case太麻烦、需要测试的逻辑过多甚至代码太多看得我眼花，那我就认为设计有问题需要重构或者重新设计。
一般情况下，如果test case很复杂，说明目标class或者interface肩负的责任太多的缘故。

我的经验是，首先将逻辑隔离，尤其是数据访问逻辑，然后单独测试，重要的是，从来不对隔离出来的数据访问逻辑进行单元测试，只测试剩下来的业务逻辑（这时候当然要用Mock），隔离的好的话，数据访问逻辑只剩下CRUD，没什么好测的。测试数据访问逻辑不划算，代价太高，付出收获不成比例。

涉及到真实数据的数据层测试还能算是unit test么？
这种情况应该算是integrating test了吧。
看看spring中关于这部分的测试，想法非常好。在一个事务中调用dao的方法，再用jdbc取相应的数据，assert，最后再rollback，根本不用担心数据污染的问题。
最好用上jdbcunit这个开源包，非常的简便。

我不这么认为。
我是这样做的，不知道对不对：
如果我抽象出了一个dao层的话，那对业务逻辑就用mock测，dao层和数据库一起集成起来测试。
如果没dao层，那就把业务逻辑和数据库一起集成起来测试。

总之，数据访问逻辑我肯定要测的，而且不会只测逻辑，而是和数据库集成测试。

代价很高吗？我觉得不会呀。数据访问逻辑在很多应用中都是最重要，这都不测那*&^%&

代价高不高就看你对测试的要求了，如果要测试能够在无人干预的情况下自动反复运行就有的折腾了。如果你的测试程序只能保证第一次运行的时候可以工作，第二次就不好说，那么还不如不写。

麻烦就麻烦在数据库的状态的恢复，这个问题解决了，就好的多。

这有什么好麻烦的？
我是在setUp()中把table，sequence等等全部drop掉重建（用hibernate），然后用一个jdbc工具插入所有的测试数据
这样速度可能会慢点，但保证了测试的隔离。

More detail please.