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

Question

我目前正在学习黄瓜，在非常简单的测试中，我有一些疑问：“如何组织我的StepClasses的最佳方法。

这是我的.功能：

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

还有我的阶梯班：

公共类步法 {

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（） 应该留在这里，还是留在另一个步骤类中？另一个问题，如果我想使用场景大纲，在这种情况下我会怎么做？因为答案会有所不同，尽管添加/删除的马铃薯是相同的。有一些好的实践可以指导构建黄瓜测试的过程？

Answer 1

就 Step 与要测试的方案相关而言，最好在单个 Step 类文件中找到这些步骤。对于场景大纲，它可以是这样的：从袋子中添加/删除土豆。：在给定袋子有“10”个土豆而不是你使用它的一个场景中使用变量，从长远来看会有所帮助。

Answer 2

关于如何构建功能文件和步骤定义，有很多不同的意见，其中很多都归结为偏好和项目的需求。我在这里的所有想法都是关于通过浏览器对大型项目进行系统测试的，这可能与每个人无关。也就是说，我运气最好，功能与步骤之间存在1对1的关系。我喜欢使用一个步骤 def 来提供单个功能文件，并避免重用步骤作为保持代码 DRY 的主要策略（这就是页面对象的用途！偶尔重用一个步骤是有意义的（例如，鉴于我已经登录），但我的经验是，它会导致建立这些非常小的原子步骤的大库，这些步骤很难找到，难以重用，并将小黄瓜推向极致。1对1方法（除了在黄瓜文档中违反这种反模式之外）的明显抱怨是，它会导致重复的代码，但我发现任何你想多次做的事情都可能是一个通用的操作，可以向下推送到页面对象。这在步骤定义中留下的很少，除了特定于正在测试的业务规则的代码，无论如何您都不需要复制这些代码。如此简短的回答，我将与该功能的其他步骤保持在同一类中。但就像你说的，你的例子很简单，所以我猜测你的项目最终会是什么需求。i_remove_one_potato()例如大纲，您应该能够执行如下操作Scenario Outline: I add/remove potatoes from bagGiven the bag has <initial> potatoesWhen I <add_remove> <delta> potatoesThen I should be told <outcome> potatoesExamples:| add_remove | initial | delta&nbsp; | outcome || add&nbsp; &nbsp; &nbsp; &nbsp; | 10&nbsp; &nbsp; &nbsp; | 1&nbsp; &nbsp; &nbsp; | 11&nbsp; &nbsp; &nbsp; || add&nbsp; &nbsp; &nbsp; &nbsp; | 10&nbsp; &nbsp; &nbsp; | 10&nbsp; &nbsp; &nbsp;| 20&nbsp; &nbsp; &nbsp; || remove&nbsp; &nbsp; &nbsp;| 10&nbsp; &nbsp; &nbsp; | 1&nbsp; &nbsp; &nbsp; | 9&nbsp; &nbsp; &nbsp; &nbsp;|| remove&nbsp; &nbsp; &nbsp;| 10&nbsp; &nbsp; &nbsp; | 10&nbsp; &nbsp; &nbsp;| 0&nbsp; &nbsp; &nbsp; &nbsp;|我尽量不要用场景大纲过度使用它，但这可能走得太远了。将整个功能归结为一个由通用步骤驱动的编程表可能很诱人，但在某些时候，很难提取出各个业务规则是什么。当一个示例开始失败时，您必须将整个事情分开，并找出作者为什么选择他所做的表值。BDD工具应该照亮该功能，而大型表格往往会掩盖它。对于上面的示例，我可能应该将添加和删除拆分为单独的大纲，因此我不会将不同业务规则的示例混合在一起。