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

时间:2019-04-04 17:42:37

标签: java testing cucumber

我目前正在学习黄瓜,在一个非常简单的测试中,我有一些疑问: “组织我的StepClass的最佳方法是什么。

这是我的.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()应该留在此处还是在另一个步骤类中? 另一个问题,如果我想使用方案大纲,在这种情况下我将如何做?尽管添加/删除的马铃薯相同,但答案会有所不同。 有好的实践指导您构建黄瓜测试的过程吗?

Thx

2 个答案:

答案 0 :(得分:1)

到目前为止,步骤与要测试的场景有关,因此最好在单个“步骤类”文件中找到步骤。对于方案大纲,它可能像是:从袋子中添加/删除土豆。

:在类似场景中使用变量 考虑到袋子里有“ 10”土豆 而不是您将要使用的它将长期有效。

答案 1 :(得分:0)

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

也就是说,我在功能和步骤之间是一对一的关系,这真是太幸运了。我喜欢一步定义服务单个功能文件,并避免将步骤重复用作保持代码DRY(这就是页面对象的目的!)的主要策略。有时重用某个步骤很有意义(例如,假设我已经登录),但是我的经验是,它导致建立这些非常小的原子步骤的大型库,这些库很难找到,难以重用,并且使小黄瓜变得势在必行。

采用一对一方法(而不是在黄瓜文档中违反this anti-pattern)的明显抱怨是,这将导致重复的代码,但是我发现您想要做的更多事情一次以上的操作可能是可以将其下推到页面对象的通用操作。除了特定于要测试的业务规则的代码外,这在步骤定义中几乎没有留下任何用处。

答案很短,我将SELECT i.*, g.* FROM items i LEFT JOIN gallery g ON i.item_id = g.item_gal_id WHERE i.it_public = 'SI' AND NOT EXISTS ( SELECT 1 FROM gallery g1 WHERE i.item_id = g1.item_gal_id AND g1.img_order < g.img_order ) ORDER BY i.item_order 与该功能的其他步骤保持在同一类中。但是就像您说的那样,您的示例很简单,所以我猜测您的项目最终将是什么。

例如轮廓,您应该可以做类似的事情

i_remove_one_potato()

尽管如此,我还是尽量不要过度使用它,这可能太过分了。将整个功能分解成由通用步骤驱动的一个编程表可能很诱人,但是在某些时候,很难提取出各个业务规则是什么。当单个示例开始失败时,您必须将整个过程拆开,弄清楚作者为什么选择他所做的表值。 BDD工具应该可以照亮该功能,而大表可能会使其模糊。对于上面的示例,我可能应该将添加和删除拆分为单独的轮廓,因此我不会将不同业务规则的示例混在一起。

有些想法!祝你好运!