与我的前一个问题相反,我将尝试给出我的需求。
我正在设法找到一些框架/方法/“东西”适合以下方面:
我的第一次尝试是使用NUnit测试来驱动Selenium (以及之前的Watin ),但是在使用TransactionScope回滚硒驱动浏览器在DB中所做的更改时,我遇到了一些问题(查看上面的链接)。
有没有人在“现实世界”做过这样的事?我已经通过Google找到了一些参考资料,但是还没有找到任何具体的例子来说明如何实现这一点。如果我在做单元测试,就不会有任何问题了。在这种情况下,TransactionScope就足够了。
编辑: R.哈维向我指出了这的问题,这个问题与我的情况几乎完全相同。
然而,这个问题几乎完全相同。我的应用程序是服务系列的一部分,所有这些服务都访问同一组数据库表。所需的测试数据量不允许有效地使用drop/create脚本,因此是否有其他解决方案?
我们正在使用Server 2005,而我对数据库魔术并不十分精通,所以如果有一些方法可以使用SQL脚本,而不是drop/create,那么这可能是一种选择。
编辑2:
基于答案和一些额外的抓取,我们将为开发人员提供更轻量级的数据库,以执行单元、集成和功能测试。这使我们能够使用sql脚本来设置和删除测试。
发布于 2009-09-24 06:12:27
在事务中所做的更改仅在所述事务中可见。此外,将测试封装在事务范围(如果可能的话)将使测试在一个非常关键的方面(事务)中的行为与真实的测试不同。
最好在每个测试套件之前使用您还原的数据库映像。这样,在套件完成并完成验证之后,您将删除测试数据库。下一次运行时,在套件设置期间,数据库将从保存的映像中重新创建,处于原始状态,可以进行测试。更好的做法是有一个脚本,从零开始部署数据库,并在套件安装期间运行该脚本。
顺便说一句,在每次测试之前恢复到原始状态是不可行的。更一般地说,进行冗长的单独测试设置和清理步骤是不可行的。随着您添加更多的测试,在测试之间将数据库恢复到测试就绪状态所花费的时间将变得难以管理。拥有数百个测试的套件是非常常见的,完整的测试运行数以万计的测试意味着只需要为测试恢复数据库花费了几个小时和几个小时。设计您的个人测试,以便它们能够独立运行。测试N必须产生有效的结果,即使测试N1失败.
另一件要考虑的事情是失败调查,您希望失败的测试将数据库保持在可以调查有意义的信息的状态,并且希望后续的测试能够运行并产生有效的结果。有时,这些需求会相互矛盾,但您必须考虑到它们,并围绕它们设计测试。
发布于 2009-09-24 07:27:06
如果将数据库还原到已知良好状态所需的数据量限制在drop/create脚本上,并且您正在SQL 2005的Developer或Enterprise上运行测试,则可以在每次测试之前查看状态良好的创建数据库快照和再回到它。这比完全恢复要快得多,尽管如果您有数百个测试,它可能仍然太费时了。
https://stackoverflow.com/questions/1469844
复制相似问题