2

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

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

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

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

我的问题如下：

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

1 回答 1

1

围绕 DAO 进行测试总是很棘手，但如果你在这一层中有逻辑，那么它绝对是单元测试的好候选。

我过去发现使用内存数据库进行这种类型的测试效果很好 - 涉及一定数量的设置成本（即配置您自己的数据库模式的连接和部署作为测试的一部分）但是一旦完成，它们往往会很好地工作。SQLite看起来对您来说可能是一个不错的选择，看起来它与 NHibernate 一起使用相当简单，并且还有一个用于 ADO.net 的 SQLite 提供程序。

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

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

于 2013-07-08T08:39:52.480 回答