当我在不同角色中拥有相似的 Gherkin 场景时，如何避免重复自己？

Question

我正在编写 Gherkin 场景，遇到了一个问题，即用户故事适用于我们正在设计的系统中的多个角色，但存在细微差别。

根据我的阅读，首选的方法是从这个角度编写Feature文件：

作为[角色/角色]

我想要[功能]

这样[好处]

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

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

解决此问题的一种方法是围绕实体（申请人）而不是角色来定位特征/用户故事，即

功能

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

我希望能够查看申请人

这样我就可以履行我的工作职责

场景

当我请求查看申请人时

然后我将根据我的权限查看允许我访问的申请人

这个场景简洁地捕捉了用户故事。但是，我想测试不同的用例，即分公司经理只能查看分配给他的分公司的申请人，区域经理只能查看分配给他的地区的申请人，客户只能查看他们公司工作分配的申请人。

解决此问题的最佳方法是什么？您认为围绕实体而非角色编写用户故事的方法是否可以接受？

Answer 1

我会少担心重复，多关注清晰度。

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

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

如果您发现存在许多差异非常小的变体，请考虑使用场景大纲来捕获所有不同的版本。这可以减少重复，同时仍然清楚差异。

如果更改更多是技术性的，而您的利益相关者并不关心，那么使用单元测试来捕获实现，而不是 Gherkin。

但在这种情况下，请少关注重复，多关注创建易于沟通的共识。

请记住，Gherkin 是一种交流工具，而不是一种编程工具。作为一种通信语言，除编程语言外，其他规则也适用。

Answer 2

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

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

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