我知道这个问题已经被问过很多次了，但我仍然没有找到一个好的答案，而且我对这个问题的看法略有不同。
我正在寻找一种对数据访问层进行彻底单元测试的好方法，但如果可能的话原子测试。我不想使用真正的数据库(或克隆)，因为这将是一个集成测试，我希望我的测试尽可能保持轻量和简单。
DAL使用NHibernate实现，DB为Microsoft SQL Server。不幸的是，一些 DAO 将不得不使用普通的旧 ADO.Net 来实现。更糟糕的是，某些 DAO 必须是存储过程的包装器。
基本上，我想要测试的是 NHibernate 映射是否有意义，以及 DAO 是否从根本上起作用。我想根据我的 NHibernate 映射在内存中创建一个数据库，模拟所有需要的存储过程，然后围绕这个数据库运行我的单元测试。使用我正在测试的 DAO 从内存数据库中的“模拟”插入和查询。
我的问题如下:
- 这是一个好方法吗？
- 是否有人对这种方法有经验并可以分享见解？
- 是否有某种框架或库可以帮助我在内存数据库中创建模拟？
- 我如何构建这些测试以适用于基于 NHibernate 的 Dao 和基于 ADO.Net 的 Dao？
- 如何为存储过程创建模拟？
最佳答案
围绕 DAO 进行测试总是很棘手，但如果您在该层内有逻辑，那么它绝对是单元测试的理想选择。
我过去发现，使用内存数据库进行此类测试非常有效 - 涉及一定数量的设置成本(即配置您自己的数据库模式的连接和部署作为测试的一部分)测试)但是一旦完成，它们往往会很好地工作。 SQLite看起来这对您来说可能是一个不错的选择，看起来很简单 use with NHibernate , 还有一个 SQLite provider for ADO.net .
对于您的问题，SQLite 的一个问题是它不支持存储过程。我认为你最好的选择是创建单独的类来封装存储过程调用，并将这些类型的对象依赖注入(inject)到你的 DAO 中。这样，您就可以使用标准对象模拟来模拟存储过程调用。
最后一点——如果你的应用程序中确实有包含任何重要逻辑的存储过程，那么围绕这些进行一些集成测试可能是值得的(也许每个存储过程一个测试来执行 DAO 和部署在数据库之类的产品)。尽管创建和维护它们会有些痛苦，但我发现这些在过去非常值得 - 对存储过程的更改通常是错误的来源，因为开发人员很少对存储过程的更改进行足够彻底的测试。
关于.net - 单元测试数据访问层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17511088/