如何对数据源层进行单元测试

在典型的三层架构中，有一个独立的数据源层。主要是用来进行数据的持久化。当然，绝大部分都是数据都是存储在关系数据库中。我们一般会使用DAO模式来屏蔽数据存、取的细节，它只是暴露接口给调用它的业务逻辑层，具体接口的实现会有很多种方式，比如：JDBC,Hibernate,JDO, JDBC, iBATIS, JDO, Entity Beans等。在下面的讨论中假设使用的是现在非常流行的Hibernate。
总的来说有两种方法：使用Mock对象和直接在关系数据库中测试。
一、 使用Mock对象来测试DAO。它屏蔽了具体的关系数据库，它的优点是测试代码的编写方便，可以快速运行。缺点：风险太大，对数据层测试的力度太小，屏蔽了很多与数据库相关的问题，比如：对象和数据库表之间映射，查询语句的语法是否正确。
二、 直接在关系数据库中测试。优点：能对数据层进行完整的测试。缺点：单元测试运行速度太慢，要频繁的对数据库进行操作。
我个人在实际项目中，使用第二种方法对数据层进行测试。虽然这样的单元测试运行比较慢，但却可以在早期对数据源层进行彻底的测试，降低项目的风险。
数据源层测试的内容：
1、 实体关系测试：关联（一对一、多对一、一对多，多对多）、继承（类的继承，接口的继承）。主要是测试实体对象和表（数据库中的表）之间的映射。
2、 查询语句的测试。首先肯定是要保证查询语句语法的正确，我认为查询结果的正确性也应该是由单元测试来保证的（有些观点认为查询结果的验证是集成测试的范畴）。
3、 对简单的get()和set()方法就不用浪费时间测试了，很简单的CRUD操作不测试也可以，但如果其中有逻辑部分则是一定要测试的。