拥有特定的用户故事场景是邪恶的吗？

Question

所以我知道，当涉及到用户故事场景时， 具体 是 好东西。然而，我经常会问自己：我的场景应该有多具体？

例如，对于用户故事：

为了让项目成员能够在项目上进行协作，作为项目经理，我希望能够注册新项目

我们可以有以下场景：

假设一个项目从未在系统中注册过，当项目经理注册该项目时，注册的项目应该出现在指定成员的项目列表中

或者我们可以更具体一些，例如：

鉴于Scott是项目经理，并且stackoverflow集成项目从未在系统中注册，当Scott注册stackoverflow集成时项目指定Jane作为项目成员，那么stackoverflow集成项目应该出现在Jane的项目列表中

em> 指定 Jane 作为项目成员，那么 stackoverflow 集成项目 应该出现在 Jane 的我找到的第二个 ”更具体”，写作时方便BDD 规范。使用 scottTheProjectManager 而不是 projectManagerStub 之类的东西的地方是：

• 更符合现实世界（我们没有作为项目经理工作的存根......或者我们吗？）
• 在该规范上下文中需要时更容易引用（否则，我将保留说“那个项目经理”或“注册该项目的项目经理”......等等。

当故事发生变化时，这种特殊性会伤害我吗？

非常感谢！

---

Update

上面的问题不仅涉及使用人名而不是角色名称，还涉及将场景中的所有占位符替换为真实实例的名称。在真实的例子中，我并不是说我们实际上有一个叫斯科特的人担任项目经理，它只是为抽象占位符命名以实现上述好处。

我将尝试通过包含以下代码来展示如何实现这些好处，该代码代表使用 StoryQ 框架的完整 BDD 样式规范

[TestFixture]
public class ProjectRegistrationSpecs
{
    [Test]
    public void ProjectRegistration()
    {
        new Story("Project Registration")
            .InOrderTo("allow project members to collaborate over a project")
            .AsA("project manager")
            .IWant("to be able to register new projects")
                .WithScenario("New Project Registration")
                    .Given(ScottIsAProjectManager)
                        .And(StackoverflowIntegrationProjectHasNeverBeenRegistered)
                    .When(ScottRegistersStackoverflowIntegrationProjectSpecifyingJaneAsAnAnalyst)
                    .Then(StackoverflowIntegrationProjectShouldAppearInJanesListOfProjects)
        .Execute();
}

//Since Scott and Jane are just instances that have meaning in the context of this user story only, they're defined private
private ProjectManager scottTheProjectManager;
private Project stackOverFlowIntegrationProject;
private Employee janeTheAnalyst; 

    //Initialize the stubs in the constructor
    public ProjectRegistrationSpecs()
    {
        scottTheProjectManager = new ProjectManager()
        {
            Id = new Guid("{A1596CFC-5FA5-4f67-AC7E-5B140F312D52}")
        };

        stackOverFlowIntegrationProject = new Project()
        {
            Id = new Guid("{F4CD5DDE-861E-4e18-8021-730B7F47C232}"),
            Name = "Stack Overflow Integration"
        };
    }
    private void ScottIsAProjectManager()
    {
        container.Get<IDataProvider>().Repository<ProjectManager>().Add(scottTheProjectManager);
    }
    private void StackoverflowIntegrationProjectHasNeverBeenRegisteredInTheSystem()
    {
        var provider = container.Get<IDataProvider>();
        var project = provider.Repository<Project>().SingleOrDefault(p => p.Name == stackOverFlowIntegrationProject.Name);
        if (null != project)
        provider.Repository<Project>().Delete(project);
    }
    private void ScottRegistersStackoverflowIntegrationProjectSpecifyingJaneAsAProjectMember()
    {
        stackOverFlowIntegrationProject.Members.Add(janeTheAnalyst);
        scottTheProjectManager.RegisterProject(stackOverFlowIntegrationProject);
    }

    //instead of saying something like TheProjectThatWasAddedByTheProjectManagerShouldAppearInTheProjectMembersList, we have: 
    private void StackoverflowIntegrationProjectShouldAppearInJanesListOfProjects()
    {
        Assert.That(janeTheAnalyst.Projects.Any(p => p.Id == stackOverFlowIntegrationProject.Id));
    }
}

Answer 1

“用户角色”是一个非常强大但难以掌握的概念。如果做得好，它们可以引导您获得简化、优化的用户体验。如果做错了，他们会占用时间，并给团队中的人一个互相吼叫的主观理由。

查看 http:// www.agile-ux.com/2009/12/02/personas-in-agile-development-yes-we-can/ 作为起点。关于这个主题的文献有大量，但大多不是专门针对 BDD 的。

我能给出的最重要的建议是，在定义你的角色时，重要的是要非常具体地说明什么让他们高兴/激励/沮丧，但这种特殊性应该是针对整个世界或一般计算而言的 - 唐不要将这些东西与产品的特定方面或个人对产品的期望联系起来，否则 1) 角色很快就会过时，需要重新创建；2) 这些人最终会被用作主观武器，以进一步提升你的个人能力。愿望，而不是作为基于事实的工具来改进为真实的人们提供最好的产品。这说起来容易做起来难。

Answer 2

您给出的第一个“场景”实际上是验收标准。它指定了一条适用于所有类型的项目经理、成员和特定项目的规则。

第二个场景是使用实际数据的验收标准的示例。 BDD 最重要的方面是在对话中使用这样的例子，以便可以讨论故事接受标准的任何其他方面。

例如，假设 stackoverflow 集成项目已经注册，当 Scott 尝试再次注册它时会发生什么？是否有任何情况可以拒绝 Jane 的项目分配？ Jane 的项目分配是唯一有价值的成果吗？她会收到有关此事的电子邮件吗？

您可能已经看到在讨论场景时使用特定数据是多么容易。还要记住：

• 进行对话比
• 捕获对话更重要，而捕获对话又比
• 自动化对话更重要。

如果您能够同时完成这三件事，那就太好了，但不要为了自动化而在对话上妥协。

Answer 3

为其中的角色使用名称是好，因为它们可以让故事更容易理解；它们更多地调动你的灵长类大脑，因为它喜欢个体而讨厌抽象。不过，你一定要小心！尽量确保你使用的名字与你实际合作的任何人的名字不匹配——这会非常令人困惑——并且不要编码偏见——这个项目不是一个带有偏见的东西，因为它不能有意见。不同的角色也不要使用相同的名称；虽然现实可能是一个混乱的混合体，人们扮演着许多角色，但用户故事不应该以这种方式混合在一起，因为这很容易令人困惑。

Answer 4

比较您的示例中的以下内容：

鉴于 Scott 是项目经理，且从未在系统中注册过 stackoverflow 集成项目，当 Scott 注册 stackoverflow 集成项目并指定 Jane 作为项目成员时，则 stackoverflow 集成项目应出现在 Jane 的项目列表中

VS：

给定一个项目经理和一个未注册的项目，当项目经理注册该项目并指定一个团队成员时，该项目应出现在该团队成员的项目列表中。

请注意，上面第二个示例的措辞与您在问题中给出的第一个示例并没有太大不同，但略有不同，因此读起来好像更完整一点。我认为在某种程度上，这就是你可能觉得缺失的东西，如果是这样的话，我会将其视为一种“故事味道”，如果是这样的话，我会不断提出问题并重新措辞，直到故事/场景感觉更完整。

就我个人而言，我发现角色的使用分散了我对手头任务的注意力，而且我不喜欢最终我的测试代码中充满了读起来不属于我正在测试的内容的文本。另一方面，如果您采用数据驱动的方法，并且为此目的定义了某种数据结构，那么使用在测试范围内有意义的名称填充该结构是有意义的。

我认为使用角色的风险之一是它们有时最终会成为懒惰方法命名的替代品，或者更糟糕的是，作为无聊的程序员尝试在代码中注入一点幽默的手段。我并不是认为用你的名字来取乐有什么不好，但如果它们不能为利益相关者提供价值，那么就不应该使用它们。

不过，我想到了另一个想法，那就是你可以两全其美。如果您将用户角色指定为要提供给故事场景的数据，那么您将受益于保持代码简洁、切题，而且还可以使输出在实际测试执行方面显得更加具体。例如：

new Story("Project Registration")
        .InOrderTo("allow project members to collaborate over a project")
        .AsA("project manager")
        .IWant("to be able to register new projects")
            .WithScenario("New Project Registration")
                .Given(AProjectManager, "Scott")
                    .And(AnUnRegisteredProject, "Stack Overflow Integration")
                .When(TheProjectManagerRegistersTheProject)
                    .And(TheProjectManagerSpecifiesATeamMember, "Jane")
                .Then(ThenTheProjectShouldAppearInTheTeamMembersListOfProjects)
    .Execute();

Answer 5

虽然您的方法具有指定的特定用户间隔，但对于领域专家来说更容易理解（因为
领域专家知道 *Scott_the_project_manager* 和他的任务），但我认为这种方法违反了 Single_responsibility_principle：一个人可以有多种角色。

Scott 还可能参与营销工作，*Magret_the_project_manager* 可能与 Scott 有不同的职责