黄瓜 - 测试原则与速度

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

普通用户很少发生这种情况，对吧？除非您涉及某些特定的 admin/dev 案例。如果您将它用作前提条件，请查看 xUnit Fixture Setup patterns. DB validations are a recommended consideration，只是不在框架的最顶层。

和

greatly cutting execution time

可以通过并行执行您的 features/scenarios 来实现。不是，通过削减测试场景。同样，权衡有利于有意义的场景。

黄瓜 - 测试原则与速度

Cucumber - testing principals vs speed

automation

automated-tests

cucumber

selenium-webdriver