多个角色

正如我的无处不在的语言，我有一些短语，如小黄瓜单一特征：多个角色

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（和相同的测试代码，生产代码，databse ...）具有多个角色和refactor当他们的要求迫使我分开他们？

来源

2016-07-19 Mohsen

对不起，在这里看不到任何用户故事。 –

@Eugene S：对不起，我刚刚添加了更多信息 – Mohsen

我不知道你在这里的问题，并会尝试猜测。所以首先，你的前三行只是一个描述而不是真正的步骤。这使添加不会运行的自定义文本成为可能。

至于其他2个步骤，很难说它们是否好。正如您可能已经注意到的那样，您不受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值改变运行一个。

现在，关于您未来可能的变化。你不能总是预测未来会发生什么，除非持续改变目前的要求对你或你的团队来说是正常的做法，我不会太担心这一点。如果在未来的当前情景中某个时候会过时，您将检查它们并重新编写它们或相应地添加新的。

来源

2016-07-19 15:26:44

谢谢，我刚刚添加了更多信息。 – Mohsen

@Mohsen看我的编辑 –

我认为这里的问题是你的语言需要改进以澄清你想在这里做什么以及为什么它是重要的。

在我看来，作为一名管理员，希望在文章中解决错误，我需要的是能够更改文章。

类似的事情适用于客户（应该是作者？）。如果你研究一篇文章被错误编写后他们会做什么，那么你可能会发现不同的角色以不同的方式进行交互。您将开始询问有关如果客户和管理员进行修复会发生什么的问题，以及当管理员修复客户不喜欢的情况以及各种其他情况时，客户如何响应。

如果您这样做，您可能会发现大部分重复数据都会消失，并且您将在此特定上下文中了解客户和管理员行为之间的差异。

来源

2016-07-20 16:24:37 diabolist

如果某个功能需要多个角色，那么这意味着它是史诗般的，而不是功能。分解每个功能是必须的，因此它只有一个角色，并且可以为单个用户组提供单个值。

来源

2017-07-22 02:37:29

回答

相关问题