单元测试实践小结3

使用成熟单元测试框架

    除了最基本的Junit外，Opensource提供了很多非常有价值的单元测试框架，熟练使用这些工具，可以提高测试的效率。包括对准备大量的数据，以及j2ee的框架代码。
现有代码的可选自动化测试工具：
1. POJO：JUnit, JMock或者EasyMock
2. Data Object：DDTUnit。准备大量数据。
3. Dao：DBUnit。初始化数据库。批量产生数据库数据。
4. EJB： MockEJB或者MockRunner
5. Servlet：Cactus
6. Struts：StrutsUnitTest
7. XML:XMLUnit
8. J2EE: MockRunner
9. GUI: JFCUnit, Marathor
10. Other: JTestCase(采用XML定义测试过程)

分层架构下的单元测试

1 Web层的单元测试
主要测试Controller的数据结构化逻辑
如果View是利用模板引擎的，需要测试页面的控制脚本是否正确。

2 Domain Service的单元测试
包括业务规则和业务流程。
Service有四种参与对象，如下：
1. Domain Object
2. Dao对象
3. 其它Service服务。
4. 工具类

产出物：
1. 返回值包括POJO，和结构化的数据（如XML）
2. 传递给流程节点的参数值。

特点：
    概念上，业务逻辑和业务流程是相对独立的。实际代码，虽然一些业务逻辑是相对独立的。但是有一些业务逻辑与流程合在一起。由于业务逻辑有明确的返回值，业务规则可以独立成一个方法，其是有显示的返回值，这样UnitTest就可以focus在业务规则的测试上。而业务流程通常没有显示的返回值，在很多实践中表现为写表动作，测试比较麻烦。
同时，不过的实际情况是业务规则和业务流程是合并在一起的。

测试的应覆盖：
1. 返回值包括POJO，或者结构化的数据如XML可以利用XMLUnit来解决。
2. 流程节点的访问，以及传递给流程节点的参数值。即对业务流程的测试，可以使用上面的访问点的方法。
3.Dao的单元测试

第一个面临的问题是：做Dao数据访问层的单元测试时机。another word也就是要不要做单元测试。
几种情况是不用测试的
1. 如果Dao就是简单的CRUD，那么不用测；在未来当我们使用1.5的范型后，这些CRUD只要在父类做一边里就可以了。
2. 如果hbm文件是自动生成的，那也不用测。

以下是要测的情况：
1. 如果hbm文件是手工写的，那么需要你保证hbm的正确性。如何测试，后面再说。
2. 如果Dao中包括了一些组合查询，那么这是一种逻辑，就应该去测；如果Dao的查询还包含了某个排序机制，这个排序逻辑依据的是业务字段，那么也是要测的。（理由是：这些逻辑可以在java代码实现，不过是性能太差了，但是既然java代码的逻辑要测，那么我们没有理由不去测在sql中的逻辑）。

第二个问题如何测试：
0. 测试数据准备
可以将BA准备的数据导出。在利用Excel编辑产生一批数据。
但是每个UnitTest测试本身应该focus一个关注点上，所以每个UnitTest的数据保持在较少的水平上。
另外由于DBUnit导入数据的顺序是依据sheet的顺序的，请注意把所有外键表在前，否则插入数据时，会报外键不存在错误。

1. 数据库的选择
a.可以直接用小组用的开发数据库。优点：现成的， 所有schema都建好了。缺点：目前数据库的数据干净性无法保证，连接速度太慢。
b.使用hsqldb。优点：利用其内存模式，可以随测试程序启动，简单小巧，schema可以自行定义，每人各自一套互不影响。 缺点：无法提供PLSQL支持。出于UnitTest本身的要求，以及性能上考量，大部分情况下，建议使用hsqldb，对于涉及到PLSQL的，需要mock处理。

2.测试hbm
利用hsqldb内存数据库，在setup的时候，利用hibernate的SchemaExport工具类，将hbm导出成数据库的schema，如果有确实有潜在问题，那么测试程序将不通过。

3.测试Dao
很简单了，调用dao程序操作。对于save，update和delete操作的。需要利用原始的connection执行查询验证。对于组合查询的和逻辑排序的，就是一般的做法了。

4.在使用DBUnit时,测试非只读操作时,我们经常会采用 DatabaseOperation.CLEAN_INSERT 策略.在关联表比较多时,效率会很差.因为每次setUp,tearDown时都会重新先Delete,再Insert所有的数据.另外,我们还有一种数据库操作测试的策略,就是使用真实数据库,在每次操作完毕后都回滚事务.

1