为什么在测试运行后清理数据库?

时间:2014-11-17 13:51:33

标签: testing automated-tests integration-testing

我有几个测试套件,可以在运行时从专用数据库读取和写入数据。我的策略是假设数据库在运行测试之前处于不可靠状态,如果我需要某些表中的某些记录或空表,我会在测试运行之前进行设置。

我的态度是不在每个测试套件的末尾清理数据库,因为每个测试套件都应该在运行之前进行清理和设置。此外,如果我试图“在视觉上”调试测试套件,那么在测试完成后,数据库的最终状态仍然有效。

测试运行后是否有令人信服的理由清理数据库?

3 个答案:

答案 0 :(得分:2)

取决于您的测试,测试后会发生什么,以及有多少人在进行测试。

如果您只是在本地进行测试,那么不,自己清理后并不那么重要〜只要〜您一直采用这种理念并且您有一个流程来确保数据库处于在做除测试之外的其他事情之前已知良好状态。

如果你是一个团队的一员,那么是的,留下你的测试垃圾可以搞砸其他人/进程,你应该自己清理。

答案 1 :(得分:1)

除了之前的回答,我还想提一下,这在执行Integration测试时更合适。由于集成模块协同工作并与消息队列和数据库等基础结构相结合,因此每个独立部分都可以正常使用它所依赖的服务。

这个

  

在测试运行后清理数据库

可帮助您隔离测试数据。这里的最佳实践是将事务用于依赖于数据库的测试(例如,组件测试),并在完成时回滚事务。使用一小部分数据来有效地测试行为。将其视为数据库沙箱 - 使用隔离测试数据模式。例如。每个开发人员都可以使用这个轻量级DML来填充他的本地数据库沙箱,以加快测试执行。

另一个优点是您可以对数据库进行解耦,因此请确保应用程序向后向前兼容数据库,以便您可以单独部署它们。像 Encapsulate Table with View 和NoSQL数据库这样的模式确保您可以同时部署两个应用程序版本,而其中任何一个都不会抛出与数据库相关的错误。在一个必须使用存储过程访问数据库的项目中,它特别成功。

所有这些实际上是Virtual test labs中使用的概念之一。

答案 2 :(得分:1)

除上述答案外,我还要补充几点:

  1. DB不应该在测试后进行清理,因为那是您测试数据,测试结果和以后可以参考的所有历史记录的地方。
  2. 只有在您更改某些应用程序设置以运行您的/任何特定测试时,才应清理数据库,以免影响其他测试人员。