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。数据库验证是recommended consideration，只是不在框架的最顶层。

和

大大减少了执行时间

可以通过并行执行功能/场景来实现。不，通过削减测试方案。再次，这种权衡有利于有意义的方案。

黄瓜-测试原理与速度

2 个答案: