单元测试数据库代码

如果您想要适当的测试覆盖率，您需要两种类型的测试：

• 模拟所有实际数据访问的单元测试。这些测试不会精确地写入数据库，而是测试这样做的类的行为(它在其他依赖项上调用哪些方法，等等(

• 系统测试(或集成测试

对于单元测试，您需要模拟或存根数据访问代码，通常您有存储库接口，您可以通过创建一个将数据存储在内存中的具体存储库来存根它，也可以使用动态模拟框架来模拟它。。

对于系统或集成测试，您需要在每次测试方法之前重新创建整个数据库，以便在每次测试之前保持稳定状态。

根据前面的一些答案，如果您想测试数据访问代码，那么您可能需要考虑mock和系统/集成测试策略。

但是，如果您想对SQL对象(例如存储过程、视图、表中的约束等(进行单元测试，那么可能会对许多数据库单元测试框架感兴趣(包括我写的一个(。

一些在SQL中实现测试，另一些在代码中实现测试并使用mbUnit/NUnit等

我已经写了很多文章，并举例说明我如何处理这一问题-请参阅http://dbtestunit.wordpress.com/

其他可能有用的资源：

http://www.simple-talk.com/sql/t-sql-programming/close-those-loopholes---testing-stored-procedures--/

http://tsqlt.org/articles/

通常的方法是有一种模拟数据库操作的方法。这样，您的单元测试就不依赖于数据库是否可用或处于某个状态。也就是说，这也意味着设计有助于模拟数据层所需的隔离。单元测试以及如何做好它是一个巨大的课题。先看看Mock Frameworks和依赖项注入的谷歌。

如果您不是在开发O/R映射程序，就没有必要测试数据库代码。你不想测试ADO.NET方法，对吧？相反，您希望验证是否使用正确的值调用ADO.NET方法。

在谷歌上搜索存储库模式。您将使用CRUD方法创建IRepository接口的实现，并对其进行测试/模拟。

如果您想针对真实的数据库进行测试，这更像是一个集成，而不是单元测试。将测试封装在事务中可以使数据库保持一致状态。我们已经在基类中完成了这项工作，并使用TestInitialize和TestCleanup函数来确保这种情况始终发生。

但是，针对真实数据库进行测试肯定会给您带来性能问题。因此，从一开始就确保可以将数据库访问代码与内存中运行的代码进行交换。我现在不知道你的目标是哪个数据库访问代码，但像UnitOfWork和Repository这样的设计模式可以帮助你隔离数据库代码，并用内存解决方案替换它。