与我的previous question相比，我会尽力满足我的要求。
我正在尝试找到适合以下内容的一些框架/方法/“事物”：
我的第一次尝试是使用NUnit测试来驱动Selenium（以及之前的Watin），但我遇到了一些问题（检查上面的链接），同时使用TransactionScope回滚Selenium驱动的浏览器所做的更改DB。
有没有人在“现实世界”中做过这样的事情？我通过谷歌找到了一些参考文献，但未能找到有关如何实现这一点的具体例子。如果我正在进行单元测试，那就不会有任何问题。在那种情况下，TransactionScope就足够了。
编辑： R. Harvey向我指出this问题，这与我的情况几乎相同。
然而，这个问题只是几乎相同。我的应用程序是一系列服务的一部分，所有这些服务都访问同一组数据库表。所需的测试数据量不允许有效使用drop / create-scripts，因此是否有其他替代解决方案？
我们正在使用SQL Server 2005，而且我对数据库魔术并不十分精通，所以如果有一些方法可以使用除drop / create之外的sql脚本，那么这可能是一个选项。
编辑2：
基于答案和一些额外的头脑，我们将为开发人员提供更轻量级的数据库，以执行单元，集成和功能测试。这使我们能够使用sql脚本来设置和拆除测试。
答案 0 :(得分：7)
交易中所做的更改仅在所述交易中可见。将测试包装在事务范围内（如果可能的话）会使测试的行为与非常关键的方面（事务）中的实际行为不同。
使用在每个测试套件之前恢复的数据库映像要好得多。这样，在套件完成并完成验证后，您将删除测试数据库。下一次运行，在套件设置期间，数据库将从保存的图像中重新创建，处于原始状态，准备进行测试。更好的方法是拥有一个脚本，从头开始部署数据库并在套件设置期间运行该脚本。
在每次测试之前恢复到原始状态是不可行的。更一般地说，进行冗长的单独测试设置和清理步骤是不可行的。随着您添加更多测试，在测试之间将数据库恢复到测试就绪状态所花费的时间将变得无法管理。拥有数百个测试的套件非常普遍，数万个测试的完整测试运行意味着只需要花费数小时来恢复数据库进行测试。设计您的个人测试，以便它们可以独立运行，即。即使测试N-1失败，测试N也必须产生有效的结果。
要考虑的另一件事是失败调查，您希望失败的测试使数据库处于可以调查有意义信息的状态和您希望后续测试能够运行并生成有效结果。有时这些要求会相互矛盾，但您必须考虑它们并围绕它们设计测试。
答案 1 :(得分：7)
如果将数据库恢复到已知良好状态所需的数据量超出了删除/创建脚本并且您正在运行SQL 2005的开发人员版或企业版上的测试，那么您可以查看creating a database snapshot良好状态，并在每次测试前reverting to it。这比完全恢复快得多，但如果你有数百次测试，它可能仍然太耗时。
答案 2 :(得分：0)
不要错过我在Amnesia推荐的this related question。