单元测试数据访问层

Question

我知道这个问题已经被问过很多次了，但我仍然没有找到一个好的答案，我对这个问题的看法略有不同。

我正在寻找一种对数据访问层进行彻底单元测试的好方法，但如果可能的话以原子方式进行。我不想使用真正的数据库（或克隆），因为这将是一个集成测试，我希望我的测试尽可能保持轻量和简单。

DAL 是使用 NHibernate 实现的，而 DB 是 Microsoft SQL Server。不幸的是，一些 DAO 必须使用普通的旧 ADO.Net 来实现。更糟糕的是，一些 DAO 必须是存储过程的包装器。

基本上，我想测试的是 NHibernate 映射是否有意义，并且 DAO 基本上可以工作。我想根据我的 NHibernate 映射在内存中创建一个数据库，模拟所有必需的存储过程，然后围绕这个数据库运行我的单元测试。使用我正在测试的 DAO 从内存数据库中的“模拟”插入和查询。

我的问题如下：

1. 这是个好方法吗？
2. 是否有人对这种方法有经验并可以分享见解？
3. 是否有一些框架或库可以帮助我创建内存数据库中的模拟？
4. 如何构建这些测试以适用于基于 NHibernate 的 Dao 和基于 ADO.Net 的 Dao？
5. 如何为存储过程创建模拟？

Answer 1

围绕 DAO 进行测试总是很棘手，但如果您在这一层内有逻辑，那么它绝对是单元测试的理想选择。

我过去发现，使用内存数据库进行此类测试非常有效 - 涉及一定数量的设置成本（即，将您自己的数据库架构的连接和部署配置为测试）但是一旦完成，它们往往会很好地工作。 SQLite 看起来对你来说可能是个不错的选择，看起来use with NHibernate 相当简单，还有一个SQLite provider for ADO.net。

SQLite 的一个问题是它不支持存储过程。我认为您最好的选择是创建单独的类来封装存储过程调用，并将这些类型的依赖项注入到您的 DAO 中。这样，您可以使用标准对象模拟来模拟存储过程调用。

最后一点 - 如果您的应用程序中确实有包含任何重要逻辑的存储过程，那么围绕这些进行一些集成测试可能证明是值得的（也许每个存储过程进行一个测试，以练习 DAO 和部署在像数据库一样的产品）。尽管创建和维护这些会有些痛苦，但我发现这些在过去非常值得 - 对存储过程的更改通常是错误的根源，因为开发人员很少对存储过程的更改进行足够彻底的测试。