单元测试交流

加上了数据库就变成集成测试了吧？单元测试还是只测目标类的好，其他的对象和数据都可以mock。
以前我也总搞不清楚这个问题，搞得糊里糊涂。

建议看看Junit in action!

数据库变化，那相应的dao的代码也要变吧，单元测试应该还是那么写啊？不太明白。

有用Cactus进行容器内测试的吗?翻翻论坛的帖子提到的比较少,大都是用Mock进行容器外测试,看了看Junit in action好多在讲Cactus测试.

mock 测试速度很快,但是没有办法测试数据库的连接, 表结构, 等等.
我觉得dao的测试其实主要还是集成测试.
正如前面的同志所说, 你可以用dbunit, 或setup(建立数据)/teardown(清理数据), 但我偏好使用spring提供的AbstractTransactionalDataSourceSpringContextTests来测试, 它可以在每个测试开始一个transaction, 之后rollback. 最近我发现也可以把这个这种测试用于service层,或action层,基本不用mock, 这种形式很像rails的测试方式.

dao层绝对是要测试数据库的,使用mock那还不用测得了
其它如service层可以使用mock

使用Hibernate是一个好的办法 解决了数据库的数据发生改变时测试用例的改写.当然使用一个空的数据库也可以解决这个问题

使用Hibernate是一个好的办法 解决了数据库的数据发生改变时测试用例的改写.当然使用一个空的数据库也可以解决这个问题

扩展TestCase，或者写一些utils,实现一些数据库操作的方法，比如执行一个清库脚本，插数据脚本。
setup, teardown中保证测试数据的纯净，测试之间不会相互影响。就可以了。

单元测试，尽量让测试不依赖于业务数据。

例如：对一个业务对象的操作Customer，多数业务逻辑测试应该是new Customer（）就可以满足，不要从数据库加载，

而一些系统参数配置则放在测试数据中就可以了。

sit,uat 测试需要一整套的业务测试数据，这样的测试要求很强的数据关联行，这些测试数据最好有专人维护，而且应该相对稳定。这样才能保证测试的有效。在这个阶段 保持测试数据和测试的有效性是比较复杂的。



好的设计应该是测试友好的，但纯为了测试抽象就不必要了。

比较极端的做法是把数据库 DAO 层抽象成接口，然后做一个模拟实现。不过这样划不划得来，要看项目具体情况了。我个人做法通常是：在 setup() 中先 insert 一堆数据，然后在 tearDown() 中 delete 掉。这样就能保证单元测试不被影响。

setup()里起一个Transation
tearDown()里rollback这样更爽了