小黄瓜描述测试或功能？

Question

这是我遇到的一个有趣的话题,我的同事和我对此事有不同的看法.您的Gherkin应该准确描述测试的内容,或者只显示您在测试中尝试实现的业务逻辑.

我在工作中遇到的最大例子是,如果你有权访问项目A,那么你应该能够访问A.我们可以有20种不同类型的用户可以访问A,所以我们只选择1(让我们的测试套件不用40个小时来运行).哪个更"好"？

一个

Scenario: A user with access to item A can access A
Given I am a type 4 user with access to item A
When I try to access A
Then I am granted access to A

或B.

Scenario: A user with access to item A can access A
Given I am a user with access to item A
When I try to access A
Then I am granted access to A

注意给定语句中的差异(类型4用户)

在步骤定义中,我们将使用类型4用户进行测试,但测试并非特定于类型4用户.任何具有项目A的用户都将参与此测试,我们只是使用类型4用户,因为我们需要用户类型才能登录.

所以A描述了测试的作用(使用能够访问项目A的类型4用户登录)

B描述了访问项目A所需的功能(只是有权访问项目A的用户)

在您询问之前,我们如何确定谁有权访问项目A是对数据库的SQL调用,以查找链接到用户的特定项目.

Answer 1

对于黄瓜测试,您正在测试业务逻辑 - 作为验收测试 - 而不是特定的实现细节.所以你应该做第二个而不是第一个.如果要为类型X,类型Y和边缘情况运行测试,则您的请求规范或集成测试可以更加依赖于细节.

我认为人们可以想到这一点 - 这不是一个严格的快速规则 - 如下所示:

单元测试以隔离方法并一次测试一件事.模拟和存储其他所有内容以隔离正在测试的内容.

集成测试,用于测试事物如何相互作用以测试堆栈的大部分,包括多个对象的交互.有些人认为你在这里测试所有的汤都是坚果,但我认为在一个大型的复杂应用程序中有一个地方可以测试大量的集成,同时还没有测试完整的请求周期.

请求规范 - 有时在简单的应用程序中这些与集成测试几乎相同,在其他情况下,我将对除请求堆栈之外的所有内容进行集成测试,并特别分离出我的请求规范.意见会有所不同.

验收测试 - 这是您的问题所在 - 测试以简单的商业语言编写,并避免功能定义中的技术实现细节.

无论如何,即使你忽略了对测试堆栈其余部分的想法,在你要求的具体问题中也要去找B.