因此，您在 C# 中有一个使用存储库模式的 DAL，并且每个存储库都有一个接口。它由 ADO.NET、MS SQL Server 和存储过程调用支持。
这对于在进行单元测试时对正在其他地方使用的存储库进行存根/模拟非常有用，我喜欢它！
不过，我很乐意为 DAL 本身添加一些单元测试。最好将 Rhino Mocks 与 NUnit 结合使用。不过，如果有充分的理由证明它可以做一些 Rhino 无法解决这个问题的事情，我愿意改用 MoQ。
我宁愿在单元测试期间不让它与任何数据库对话，以保持它们更加“纯粹”，同时仍然有效地测试 DAL 本身。但是，如果在不与数据库通信的情况下无法真正有效地对 DAL 本身进行单元测试，那么内存替换或基于可移植文件的替换（与 SQL Server 和相同的 SqlConnection 和 SqlCommand 调用兼容）的替代方案是什么。
如果需要，可以重构 DAL，使其更容易注入，只要它不会同时使设计过于复杂。已经使用 Microsoft Unity，通过存储库模式进行 DI。
那些到底是什么单元测试测试？考虑典型的 DAL 代码只不过是将实际工作委托给第 3 方数据访问代码（ADO.NET、EntityFramework、NHibernate）。
我没有太多使用 ADO.NET，但我认为这个 NHibernate 示例已经足够了：
public User GetUser(int id)
{
using (var session = sessionFactory.OpenSession())
{
return session.Get<User>(id);
}
}
当然，假设代码编写正确，所有依赖项（sessionFactory即）将通过接口传递，因此易于存根，因此编写单元测试是可能的（你只需要模拟很多东西就能让它发生）。
纯粹的方法是编写这样的单元测试，因为它是另一个数据点，证明您的代码确实符合您的假设（调用Get）。但是，请注意，这样的测试相当昂贵，因为您本质上必须对提供商进行的整个数据库访问进行存根（模拟sessionFactory返回模拟会话，然后检查是否进行了调用）。
这是一个很难做出的决定（在这种情况下是否遵循纯粹的方法），因为你必须写集成测试 http://en.wikipedia.org/wiki/Integration_testing无论如何，使用真实的数据库。这些测试将涵盖一模一样区域作为您编写的单元测试，但在真实环境中工作（而不是存根环境）。
根据我的经验，单元测试 DAL 通常不值得它提供的好处，特别是与它相当高的成本（为单元测试花费时间编写代码来存根数据库环境）和适当的集成测试套件的存在相比。
最后，我建议不要在任何类型的测试中使用内存数据库。出于以下原因：
- 它很慢
- 它有几个可能难以控制的故障点（ORM 配置、内存数据库设置、可能无效的测试数据）
- 给你一种进行集成测试的错觉（虽然你没有；内存数据库的行为可能与真实的生产数据库完全不同）
除非您可以将完全相同的数据库加载到内存中，否则请坚持使用适当的集成测试（这将是 DAL 测试优先级）和独立的单元测试备份（仅当您有能力编写它们时）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
