黄瓜 - 如何构建测试步骤？

Question

我正在学习黄瓜，在非常简单的测试中，我有些疑惑：“组织我的StepClasses的最佳方法是什么？

这是我的.feature：

Feature: How many potatoes have in the sack

Scenario: I put one potato in the Bag
    Given the bag has 10 potatoes
    When I put 1 potato
    Then I should be told 11 potatoes

  Scenario: I remove one potato from the Bag
    Given the bag has 10 potatoes
    When I remove 1 potato
    Then I should be told 9 potatoes

和我的StepClass：

公共类Stepdefs {

private Integer potatoesInTheBag;

@Given("^the bag has 10 potatoes$")
public void the_bag_has_10_potatoes(){
    this.potatoesInTheBag=10;
}

@When("^I put 1 potato$")
public void i_put_one_potato(){
    this.potatoesInTheBag = potatoesInTheBag + 1;
}

@Then("^I should be told (\\d+) potatoes$")
public void i_should_be_told_potatoes(int potatoes) throws Exception {
    assertEquals(potatoesInTheBag.intValue(),potatoes);
}

@When("^I remove 1 potato$")
public void i_remove_one_potato(){
    this.potatoesInTheBag = potatoesInTheBag - 1;
}

}

这个例子工作正常，但是i_remove_one_potato（）应该留在这里，还是留在另一个步骤类？另一个问题，如果我想使用Scenario Outline，在这种情况下我会怎么做？因为添加/删除马铃薯的答案会有所不同。有很好的做法可以指导这个构建黄瓜测试的过程吗？

谢谢

Answer 1

关于如何构造特征文件和步骤定义有很多不同的意见，其中很多都归结为偏好和项目的需求。我在这里的所有想法都是通过浏览器对大型项目进行系统测试，这可能与每个人都不相关。

也就是说，我在功能和步骤之间的一对一关系中获得了最好的运气。我喜欢一步def来提供单个特征文件，并避免重复使用步骤作为保持代码DRY的主要策略（这就是页面对象的用途！）。有时候重用一个步骤是有道理的（例如，鉴于我已登录），但我的经验是，它导致构建这些非常小的原子步骤的大型库，这些步骤很难找到，难以重用，并且驱使小黄瓜必须到极致。

使用1对1方法的明显抱怨（除了在黄瓜文档中违反this anti-pattern）是因为它会导致重复的代码，但我发现任何你想做多次的事情都可能是一般行为可以下推到页面对象。这在步骤定义中留下的很少，除了特定于正在测试的业务规则的代码，您无论如何都不需要复制。

如此简短的回答，我会将i_remove_one_potato()与该功能的其他步骤保持在同一个类中。但就像你说的那样，你的例子很简单，所以我猜测你的项目最终会有什么需求。

例如，大纲，你应该能够做类似的事情

Scenario Outline: I add/remove potatoes from bag
Given the bag has <initial> potatoes
When I <add_remove> <delta> potatoes
Then I should be told <outcome> potatoes
Examples:
| add_remove | initial | delta  | outcome |
| add        | 10      | 1      | 11      |
| add        | 10      | 10     | 20      |
| remove     | 10      | 1      | 9       |
| remove     | 10      | 10     | 0       |

我尽量不要用场景概述来过度，但这可能太过分了。将通用步骤驱动的整个功能简化为一个程序表可能很诱人，但在某些时候，很难确定各个业务规则是什么。当一个例子开始失败时，你必须将整个事物分开并弄清楚为什么作者选择了他所做的表值。 BDD工具应该照亮这个特征，而大表往往会掩盖它。对于上面的示例，我可能应该将添加和删除拆分为单独的大纲，因此我不会将不同业务规则的示例混合在一起。

一些想法！祝好运！

Answer 2

到目前为止步骤与要测试的场景相关，最好在单个步骤类文件中找到步骤。对于场景概述，它可能是这样的：从包中添加/删除土豆。

：在场景中使用变量如果袋子有“10”土豆而不是你使用它的那个将有助于长远。