java Cumber如何构造测试步骤？

Question

我目前正在学习cucumber，在一个非常简单的测试中，我有一些疑问： “如何组织我的STEP课程是最好的方法

这是我的。特色：

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

还有我的同班同学：

公共类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;
}

}

这个例子很好用，但是我应该删除一个，还是留在这里，或者在另一个step类中？ 另一个问题，如果我想使用场景大纲，在这种情况下我将如何做到这一点？因为答案是不同的，尽管添加/删除的土豆是相同的。 有好的实践可以指导你的黄瓜测试的结构化过程吗

Thx

Answer 1

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

也就是说，我最幸运的是功能和步骤之间有一对一的关系。我喜欢使用一步定义来为单个功能文件提供服务，并避免将步骤重用为保持代码干燥的主要策略（这就是页面对象的用途！）。偶尔重复使用一个步骤是有意义的（例如，考虑到我已登录），但我的经验是，它会导致建立这些由非常小的原子步骤组成的大型库，这些步骤很难找到，很难重复使用，并将小黄瓜推向极端

1对1方法（除了违反cucumber docs中的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工具应该能够阐明这一特性，而大型表格往往会掩盖它。对于上面的例子，我可能应该将add和remove拆分成单独的大纲，所以我不会将不同业务规则的示例混合在一起

一些想法！祝你好运

Answer 2

只要步骤与要测试的场景相关，最好在单步类文件中找到这些步骤。对于场景大纲，它可能是这样的：从袋子中添加/删除土豆

：在场景中使用变量，如 考虑到袋子里有10个土豆 而不是一个你用它将有助于长期