我刚开始进行单元测试，并想知道如何对我的数据库进行实际更改的单元测试方法。最好的方法是将它们放入事务然后回滚，还是有更好的方法呢？
答案 0 :(得分：3)
如果您需要适当的测试覆盖率，则需要两种类型的测试：
单元测试，它会模拟您的所有实际数据访问权限。这些测试不会真正写入数据库，而是测试所执行的类的行为（它调用其他依赖项的方法等）
系统测试（或集成测试），用于检查您的数据库是否可以访问和修改。我会在这里考虑两种类型的测试：每个模型对象的简单普通CRUD测试（创建/读取/更新/删除），以及针对实际方法的更复杂的系统测试，以及您认为有趣或有价值的所有测试。这里的好习惯是让每个测试从空（或“准备好测试”）数据库开始，做它的东西，然后检查数据库的状态。事务/回滚是实现这一目标的一种好方法。
答案 1 :(得分：2)
对于单元测试，你需要模拟或存根数据访问代码，主要是你有存储库接口，你可以通过创建一个存储数据的具体存储库来存根，或者你可以使用动态模拟框架来模拟它。 / p>
对于系统或集成测试，您需要在每个测试方法之前重新创建整个数据库，以便在每次测试之前保持稳定状态。
答案 2 :(得分：1)
根据以前的一些答案，如果您想测试数据访问代码，那么您可能需要考虑模拟和系统/集成测试策略。
但是，如果你想对SQL对象进行单元测试（例如，sprocs，视图，表中的约束等） - 那么有许多数据库单元测试框架可能会引起人们的兴趣（包括我写的一个） ）。
有些在SQL中实现测试，有些在代码中实现，并使用mbUnit / NUnit等。
我写了一些文章，里面有关于我如何处理这个问题的例子 - 请参阅http://dbtestunit.wordpress.com/
其他可能有用的资源：
答案 3 :(得分：0)
一般方法是有一种模拟数据库操作的方法。因此，您的单元测试不依赖于可用的数据库或某种状态。这表示它还意味着设计有助于模拟数据层所需的隔离。单元测试以及如何做好是一个很大的话题。看一下googley for Mock Frameworks和Dependency注入的开始。
答案 4 :(得分：0)
如果要对真实数据库进行测试，那么这将更多地是集成，然后是单元测试。在事务中包装测试可能是保持数据库处于一致状态的想法。 我们在基类中完成了这项工作，并使用了TestInitialize和TestCleanup函数来确保始终发生这种情况。
但针对真实数据库进行测试肯定会带来性能问题。因此，请从一开始就确保您可以使用在内存中运行的内容交换数据库访问代码。我现在没有针对哪个数据库访问代码进行定位，但UnitOfWork和Repository等设计模式可以帮助您隔离数据库代码并将其替换为内存解决方案。
答案 5 :(得分：0)
如果您没有开发O / R映射器，则无需测试数据库代码。你不想测试ADO.NET方法，对吗？相反，您需要验证是否使用正确的值调用ADO.NET方法。
在Google上搜索存储库模式。您将使用CRUD方法创建IRepository接口的实现并测试/模拟此。