Cucumber - 测试原理与速度

Question

在阅读了很多文章之后，据我了解，所有 Cucumber 测试都应该相互独立且自治，因此这是我在自动化 Web 应用程序测试时遵循的规则。

假设我正在测试具有多个输入字段的网页。

目前，对于 CRUD 操作，我有两种类型的场景：

Scenario: Check page display correct data
  Given: I populate DB with data
  When: I open the page
  Then: Page data should match with data from DB

Scenario: Update page data
  Given: I populate DB with data
  When: I open the page
  And: I update each field with some new data
  When: I press save button to save data
  Then: Page data should match with data from DB

所以在这种情况下，我有两种情况来检查数据是否正确显示，另一种情况是更新数据并检查它，但是因为填充数据库的步骤需要很长时间（1-3 秒）我在想，为什么不将这两种场景合二为一，大大缩短执行时间：

Scenario: Update page data
  Given: I populate DB with data
  When: I open the page
  Then: Page data should match with data from DB
  And: I update each field with some new data
  When: I press save button to save data
  Then: Page data should match with data from DB

如您所见，首先我填充数据库，然后检查它是否正确显示，然后修改它并再次检查，因此我在单个场景中检查了两个 CRUD 操作（读取和更新），但是我认为这是违反原则的。

Answer 1

如果您的测试更关注集成和端到端行为而不是单元/组件行为（可能就是这种情况），那么在一个场景中组合两个 CRUD 操作是非常好的。

当然，您应该始终考虑在一个场景中投入过多与将一项功能分割成多个场景之间的平衡。当然，在场景中断言不止一件事的权衡是，当场景失败时，它可能会迫使您进行更多调试。因此，这与原则无关，而是一个有意识的选择，您可能需要根据被测应用程序的速度和稳定性重新考虑。

Answer 2

一些想法，我可以分享。

...
When: I ...
And: I ...
When: ...
...

可以变成

...
When: I ...
And: I ...
And: ...
Then: ...

如果您可以将其抽象为declarative business 函数，那就更好了。这将使您能够看到森林，而不会被冗长的端到端场景所淹没。

从最终用户的角度考虑您的 BDD 旅程很好

Given: I populate DB with data

对于普通用户非常很少发生，对吧？除非您涵盖某些特定的管理/开发案例。如果您使用它作为前提条件，请查看 xUnit Fixture Setup patterns。数据库验证是 recommended consideration，只是不在框架的最顶层。

和

大大缩短执行时间

可以通过并行执行您的功能/场景来实现。不是，通过切割测试场景。同样，权衡是有利于有意义的场景。