当我有不同人物角色相似的小黄瓜情景时，我该如何避免重复自己？

Question

我正在编写小黄瓜场景，并遇到一个问题，用户故事适用于我们正在设计的系统中的多个角色，具有细微的差异。

基于我读过，首选的方法是从这个角度写功能的文件：

作为一个[角色/人物]

我希望[功能]

使[效益]

问题在于，我最终会为每个角色写出或多或少的相同场景，这将最终导致大量重复。

举一个具体的例子，在招聘申请中，不同的角色需要能够查看在公司注册的申请人实体。唯一的区别是，根据您拥有哪些特权级别（即您的角色），即执行级别，区域经理，区域经理，分部经理，分支员工，外部客户，需要对集合应用某种过滤的申请人可以查看。

解决这一问题的一种方法是定向围绕实体（申请人）的特性/用户故事而不是假面即

特征

作为应用程序的用户（NB 。而不是提指定的Persona，我们指的是一个“通用”用户角色）

我希望能够查看申请人

，以至于当我请求查看申请人

那么我可以查看我允许基于我的许可申请，我可以履行我的工作职责

方案

这种情况简洁地捕捉用户故事。但是，我想测试不同的使用情况，即分行经理只能查看分配到其分行的申请人，地区经理只能查看分配到其地区的申请人，客户只能查看申请人在其公司的工作分配。

什么是最好的方式去做这件事，你认为围绕实体而不是角色编写用户故事的方法是可以接受的吗？

Answer 1

我不会担心重复，更关注清晰度。

如果利益相关者看到区域经理被允许查看某些内容并允许外部客户查看关于同一应用程序的其他某些内容，那么我会在Gherkin中表示这一点很重要。

我确定这些规则不会经常更改，因为它们可能位于域的核心。这意味着你不会经常更换它们。如果你需要改变它们，你的利益相关者必须很容易理解这一点。

如果您发现存在许多差异很小的变体，请考虑场景大纲以捕获所有不同的版本。这可能会导致减少重复，同时仍然清楚了解这些差异。

如果这些更改具有更多的技术性质，并且您的利益相关者不关心，那么请使用单元测试来捕获实现，而不是使用小黄瓜。

但是在这种情况下，重点不在于重复，更多的是创建一个易于沟通的共同理解。

请记住，小黄瓜是一种沟通工具，而不是一种编程工具。作为通信语言，其他规则适用于编程语言。

Answer 2

“作为[角色]”不是关于谁是该功能的用户，而是谁需要该功能。大多数情况下，这是一些需要功能的利益相关者，以便公司能够受益并做更好的业务。

就你而言，这是关于查看申请人。不同的访问应该在同一个特性文件中用更多的场景来描述。但是，您的所有访问角色对于解释此功能并非至关重要。尽管Gherkin背后的工具可以测试，但Gherkin的功能和场景更多的是捕捉它们背后的想法，而不是涵盖所有可能的场景。选择1-2个最重要的访问角色，其余的选择降低测试级别，主要是单元测试。

试着记住测试金字塔，其中验收测试只有所有测试的一小部分。