E2E测试预期结果应该硬编码还是计算?

问题描述 投票:0回答:1

我是一名 BE 工程师,在 BE 单元测试方面也有经验,但最近开始使用 Playwright 和 Cucumber 进行 FE 端到端测试。场景的预期结果应该是硬编码示例还是应该作为测试的一部分进行计算?

为了简单起见,假设我正在尝试编写一个电子商务网站折扣的测试,并且我正在编写一个测试来验证折扣金额是否正确。它将用户的购物篮总额作为输入,并执行客户端计算以应用固定的 12% 折扣,并将结果返回给用户。 我应该在测试的步骤定义中计算 12% 吗?或者我应该硬编码预期结果? 如果我对预期结果进行硬编码,功能文件将看起来像这样:

Scenario: Verify discount amount is correct
Given  the shopping basket total is 60.00
When  I click "Calculate Discount"
Then  the reduction should be 7.20

或者应该更改最后一行以像

Then  the reduction should be as expected
一样计算它,并且步骤定义文件执行类似

@Then("the reduction should be as expected")
public void theReductionShouldBe() {
    double actual = getReductionDisplayedToUser();
    double expected = basketTotal * 0.12;
    assertEquals(expected, actual);
}

实际上,我正在测试的工具的计算比仅仅算出 12% 更复杂(有多个输入,而不是只有一个),所以我对后者的问题是我在 e2e 测试中复制了所有逻辑回购。但有一种观点认为,如果逻辑发生变化,我不需要修改我的特征文件,只需更新计算中的逻辑即可。我个人更喜欢前者,因为它类似于我的 BE 单元测试的测试风格,但不确定这是否是 E2E 测试的最佳实践。

另一位同事建议我对输入实现随机性(并且这只适用于计算结果),但对我来说,理论上有一个测试,如果逻辑中存在错误,有时会失败,有时会通过,这对我来说似乎很奇怪,使得维护有点困难,例如在测试失败后检查已修复的错误。

Scenario: Verify discount amount is correct
Given  the shopping basket total is a random amount between 0.00 and 1000.00
When  I click "Calculate Discount"
Then  the reduction should be as expected

正如我所说,我对端到端测试有点陌生,我不确定是否有任何标准或最佳实践。有什么想法吗?

java cucumber e2e-testing playwright end-to-end
1个回答
0
投票

如果你按照cucumber官方场景示例文档“Writing better Gherkin”,他们已经在

Then
条件下写出了期望值

https://cucumber.io/docs/bdd/better-gherkin/#:~:text=Then%20I%20see%20%22FreeArticle1%22%20and%20%22PaidArticle1%22%20on%20the%20home% 20页

您还可以按照

Scenario Outline
,您可以测试多个条件

https://cucumber.io/docs/gherkin/reference/#:~:text=*.feature%20file.-,Scenario%20Outline,-%20Scenario%20Outline

    Scenario Outline: Verify discount amount is correct
    Given  the shopping basket total is <total>
    When  I click "Calculate Discount"
    Then  the reduction should be <expected>

 Examples:
    | total  | expected |
    | 60.00  |   7.20   |
    | -1     |   0      |

然后你可以在不同的例子中玩

© www.soinside.com 2019 - 2024. All rights reserved.