7
所以我知道，当涉及到用户故事场景时，being specific是good thing。但是，我经常会问自己：我的情景应该具体到什么程度？是否有具体的用户故事场景邪恶？
例如，对于用户的故事：
为了让项目成员合作过一个项目，作为项目经理，我希望能够注册新的项目
我们可以有以下场景：
鉴于项目从未在系统中注册过，当项目经理注册该项目时，注册的项目应该在AR在项目
或者，我们可以更具体的东西，如指定成员的名单：
鉴于斯科特是一个项目经理和从未登记在计算器一体化项目系统，当斯科特寄存器stackoverflow集成项目指定珍作为项目成员，然后stackoverflow一体化项目应该出现在项目
简的名单我已经找到了第二届‘更具体的’一书写BDD规格时得心应手。有类似scottTheProjectManager代替projectManagerStub哪里是：
- 更加符合现实世界（？我们没有存根担任项目经理..还是我们）
- 更容易指每当需要（否则，我会一直说“那个项目经理”或者“项目经理谁注册了项目”......等等
我的结论是否正确？变化发生在故事上吗？
非常感谢！
更新
上面的问题不仅是有人名而不是角色名称，它是关于与实际情况的名称替换您的方案中的所有占位符。实际上，我并不是说我们实际上有一个叫斯科特的人担任项目经理，它只是给抽象占位符命名，以实现上述好处。
我会尽量展示这些优势是如何通过包括下面的代码表示使用StoryQ框架
[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));
}
}
+1为完全敏捷宣言驱动的答案。 – 2011-04-24 06:51:08
啊，我希望。尽管敏捷宣言，开发人员（包括我自己）很容易关注这些工具。这是多年来做错了的经验，而不是做正确的做法......我猜这也是宣言的来源。当我们没有经历过自己的学习时，我们似乎总是妥协。 – Lunivore 2011-04-24 11:05:50