Question

我和我的一个同事正在争论正确的测试方法。我将尽可能中性地布置它们，并且在本文中不会发表我的意见。

这是用小黄瓜写的。替换您想要的任何伪代码。

Given I am a registered user
When I submit my credentials
Then I can login

案例一：

Given I am a registered user 
    (instantiates the user,
    stores the user to scenario-global memory,
    adds the user to the db with an API endpoint
    stores the API endpoint result to scenario-global memory [200, "Success message"])

When I submit my credentials
    (test the result of the previous step [200],
    fills the credential field(s),
    clicks submit, stores the result to scenario-global memory [200, "Success message"])

Then I can login
    (tests the results of the previous step)

情况二：

Given I am a registered user
    (instantiates the user,
    stores the user in scenario-global memory,
    adds the user to the db, tests the result of the db command)

When I submit my credentials
    (fills the UI credential field(s),
    clicks submit)

Then I can login
    (perform some operation that only a logged-in user could do [see the my profile button/call some api endpoint])

争论的是“然后”步骤是否可以依靠上一个操作的结果。

Answer 1

这取决于。首先，作为一名测试人员，我永远不会直接向DB写东西，而是在UI中注册用户以进行UI测试或调用端点以涵盖API测试场景。

此外，IMO并不是每个步骤都负责测试自己的步骤，否则就不需要'Then'Gherkin语法。这种编写用户故事的方式使非技术人员更容易理解测试场景，而商务人士则更容易理解。

对于上述两种情况，我都对情况一和您同事的建议投赞成票。

Answer 2

总体而言，当尝试从最终用户角度介绍功能时，应该针对声明性BDD方案。推送您的how down是至关重要的部分。使用Back door manipulation很棒，但是请问自己-最终用户（或利益相关者）是否真的在乎技术性？

使用API端点将用户添加到数据库中

当register user流至少通过UI覆盖一次时，

是最好的用法。在场景中混合使用API和UI可能会导致混乱和维护问题。适当的DSL应该可以为您解决。

关于

每个步骤都负责测试其自身的结果。它对过去发生的事情或未来将发生的事情不承担任何责任

类似黄瓜的框架确实使用了DI的上下文/状态，恰好为此-执行在当前World实例中运行的共享步骤。

测试有关小黄瓜的最佳做法，但可能不会

2 个答案: