Question

考虑到测试向第三方API发送消息的情况，我可以对该功能中的每个方案重复某些给定，并给出相关结果。这使得每个场景都非常复杂。

如果我不这样做，那么基本上就有隐藏的假设。我的问题是，在实践中，这些隐藏的假设是否会导致问题，以及如果利益相关者普遍理解这些假设即使没有明确说明也是如此。

任何降低风险的策略都是非常受欢迎的。我认为这导致了一个或多个场景，涵盖了“一般＆＃39; Givens和＆＃39; general＆＃39; givens + results，应该作为澄清，对于下面的场景，你可以忽略这些要求并考虑它们。我怀疑这是一个假设。

2＆＃39; general＆＃39;的示例场景和，2＆＃39;一般＆＃39;给予相关结果：

Scenario 1: An eligible order
    Given an order that has been placed yesterday
    And that has a value > 100
    And that has an order ID equal to 42
    And that has an affiliate reference equal to foo
    When the conversion for the order is sent
    Then the conversion has an ID equal to 42
    And the conversion has an affiliate ID equal to foo

Answer 1

我的方法是在功能文件的顶部放置一个详细的示例，例如：

Scenario 1: An eligible order
    Given an order that has been placed yesterday
    And that has a value > 100
    And that has an order ID equal to 42
    And that has an affiliate reference equal to foo
    When the conversion for the order is sent
    Then the conversion has an ID equal to 42
    And the conversion has an affiliate ID equal to foo

然后进一步减少冗长：

Scenario x: An eligible order does something
    Given an applicable order
    ...

使用给定适用的订单，只需按顺序调用4个原始步骤。

这提供了更清晰的功能，但是使测试仍然具有相同的特定步骤，称为＃34;引擎盖＆＃34;。

第一个场景将定义此功能文件的合格订单，后续版本将使用它们。

BDD我应该在连续的情景中重复给出和结果

1 个答案: