如何在.Net中编写数据访问层测试？

Question

是否有为数据访问层编写单元测试的框架？这有几个问题。
1.如何填充数据库？
2.我们如何确保一个测试不修改db中可能导致另一个测试失败的值？

是否有一个可以解决上述问题的良好框架？

更新：我遇到了nDBUnit，它可以解决测试数据访问层的基础架构问题。

http://code.google.com/p/ndbunit/wiki/QuickStartGuide

Answer 1

我想我会插话，因为到目前为止我真的不喜欢一些答案。

在这种情况下，无论您将其称为“单元测试”还是“集成测试”或“supercalifragilisticexpialidocious测试”都无关紧要; 数据访问组件只有一个有效的测试，它是在实际数据上测试它。显然不是生产数据，而是合理的传真。

您需要做的第一件事是get the database itself under source control。可悲的是，没有这方面的框架;微软在某些版本的VSTS中占据了一席之地，但最终结果仍然缺乏。至少在今天的世界里，你将不得不自己做很多这方面的工作。但要认真对待 - 当主要更新变得拙劣并且您需要回滚数据库时，您不会后悔。

您在源代码管理下的内容应该是生成最新架构所需的一切，通常是基线脚本，加上“配置数据”脚本（即枚举表的内容），以及升级脚本以反映最近的架构更改。这为您提供几乎在临时数据库上执行“实时”测试所需的一切。您的测试只需要从源代码控制下载这些脚本并在测试服务器和/或不同的数据库实例上运行它们，通常使用SQL Management Objects来运行所述脚本（SMO可以处理GO语句等;常规的SqlConnection不能）。

各种工具可以帮助您在测试数据库中生成测试内容。可能最受欢迎的是红门的SQL Data Generator。这些工具还可以生成脚本来创建数据，这是您在测试中使用的内容。或者，如果您这样选择，则可以从生产数据库中清除数据并使用SQL Server Management Studio编写您选择保留用于测试的任何数据。无论哪种方式，将测试数据脚本保存在源代码管理中，与架构脚本相同，并且当您需要测试DAL时，请在启动数据库实例后下载这些脚本并使用它们填充数据。

我希望是一个可以为您完成所有这些工作的框架，但是通过正确的工具，库和良好的开发实践集合，您可以使这成为一个不那么痛苦的过程。

Answer 2

真正的单元测试不会访问数据库。也就是说，mbUnit有一个rollback属性，可以用于访问db的测试。

Answer 3

在测试将访问数据库的存储库时，必须始终确保在单元测试完成后清除数据库。您可以通过在事务下运行测试来执行此操作，也可以使用MbUnit Rollback属性自动回滚更改。

Answer 4

别。单元测试不访问数据库。这就是整合或功能测试的目的。

我有一组测试可以验证管理数据库通信的代码是做正确的事情，然后尽可能不经常触摸它。

在“单元测试”中没有这样做的原因是，通过这样做，你冒着稀释“单元测试”这个短语的含义的风险，把它们变成一个测试的抓包，这通常会使它们变成更慢，并阻止开发人员尽可能频繁地运行它们。