作为我无处不在的语言，我有一些短语：
Feature : Display A Post
In order to be able to check mistakes in a post
As an admin or customer
I want to be able to view the post
Scenario : Display Post
When : I select a post
Then : the post should be viewed
这是一个正确的用户故事吗？这样的场景在UI级别上可能存在一些最小的差异。我是否应该违反DRY principle并为其他角色重复此功能？
不同的用户可能会随着时间的推移需要不同的要求，我认为这就是我们通常根据用户角色编写用户故事的原因。所以我应该担心不同角色的需求会随着时间的推移而变化，或者我可以留下单个user story（以及具有多个角色的相同测试代码，生产代码，数据库......）和refactor当他们的要求强迫我将它们分开时？
答案 0 :(得分：2)
我不确定你的问题在哪里，并会尝试猜测。首先，你的前三行只是一个描述，而不是真正的步骤。这样可以添加不会运行的自定义文本。
关于你的其他两个步骤，很难说它们是否好。正如您可能已经注意到的那样，您不受Cucumber的约束，无法拥有特定的场景流程。 Cucumber让您可以自由地设计和编写代码，使其对您和您的业务逻辑更有意义。
说，我认为在重复测试另一个角色的类似步骤时没有问题。为了使特征文件更加干燥，您可以使用Scenario Outline选项。它可能看起来像这样：
Scenario Outline: Display Post as <role>
When I select a post as <role>
Then the post should be viewed
Examples:
|role |
|role1|
|role2|
在这种情况下，两个方案一个接一个地运行，而role值根据示例列表而变化。
现在，关于您将来可能发生的变化。你无法总是预测将来会发生什么，除非不断改变当前的要求对你或你的团队来说是正常的做法，我不会过分担心这一点。如果在将来的当前场景中某个时候将过时，您将查看它们并重写它们或相应地添加新的场景。
答案 1 :(得分：2)
如果某个功能需要多个角色，那么这意味着它是一个史诗，而不是一个功能。分解每个功能是必须的，因此它只有一个角色，它可以为单个用户组提供单个值。
答案 2 :(得分：1)
我认为这里的问题是你的语言需要改进以澄清你想在这里做什么以及为什么它很重要。
在我看来，作为一名管理员希望修复帖子中的错误，我需要的是能够更改帖子。
类似的事情适用于客户（应该是作者吗？）。如果你探索一篇帖子被错误地创作后他们会做什么，那么你可能会发现不同的角色以不同的方式进行交互。您将开始询问有关客户和管理员进行修复时会发生什么的问题，以及当管理员做出客户不喜欢的修复以及各种其他方案时客户如何响应的问题。
如果你这样做，你可能会发现你的大部分复制都消失了，而且你会在这个特定的环境中学到很多关于客户和管理员行为之间的差异。