Является ли наличие определенных пользовательских сценариев истории злым? - PullRequest
7 голосов
/ 03 апреля 2011

Итак, я знаю, что когда дело доходит до сценариев пользовательских историй, является конкретным - это хорошая вещь .Тем не менее, я часто сталкиваюсь с тем, что спрашиваю себя: насколько конкретным должен быть мой сценарий?

Например, для пользовательской истории:

Чтобы разрешить участникам проектасотрудничать над проектом, как менеджер проекта, я хочу иметь возможность регистрировать новые проекты

У нас может быть следующий сценарий:

Учитывая, что проект никогда не былзарегистрированный в системе, когда руководитель проекта регистрирует этот проект, зарегистрированный проект должен появиться в списке проектов указанного участника

Или мы можем быть более конкретны с чем-то вроде:

С учетом Скотт является руководителем проекта, и проект интеграции stackoverflow никогда не был зарегистрирован в системе, когда Скотт регистрирует проект интеграции stackoverflow указав Джейн в качестве участника проекта, тогда проект интеграции stackoverflow должен появиться в списке Jane проектов

Я обнаружил, что второй "более конкретный" полезен при написании спецификаций BDD.Где наличие что-то вроде scottTheProjectManager вместо projectManagerStub:

  • больше соответствует реальному миру (у нас нет заглушек, работающих в качестве менеджеров проектов ... или нет?)
  • прощеобращаться к всякий раз, когда это необходимо в контексте этой спецификации (в противном случае я буду продолжать говорить «этот менеджер проекта» или «менеджер проекта, который зарегистрировал проект» ... и т. д.)

Прав ли я в своемВывод: повредит ли эта специфика мне, когда в истории произойдет изменение?

Большое спасибо!

Обновление

Вопрос выше касается не только имен людей вместо имен ролей , но и замены всех заполнителей в вашем сценарии с именами реальных экземпляров.И в реальных случаях я не имею в виду, что у нас на самом деле есть кто-то по имени Скотт, работающий менеджером проекта, он просто присваивает имена абстрактным заполнителям, чтобы реализовать вышеупомянутые преимущества.

Я постараюсь показать, как этиПреимущества реализуются путем включения следующего кода, который представляет полную спецификацию стиля BDD с использованием инфраструктуры 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));
    }
}

Ответы [ 5 ]

3 голосов
/ 07 апреля 2011

Первый «сценарий», который вы даете, на самом деле является критерием приемлемости.Он определяет правило, которое должно работать для всех типов руководителей проектов, участников и указанных проектов.

Второй сценарий - это пример критериев приемлемости в действии с использованием реалистичных данных.Наиболее важным аспектом BDD является использование подобных примеров в разговоре, чтобы можно было обсудить любые другие аспекты критериев приемлемости для истории.

Например, с учетом проекта интеграции stackoverflow уже зарегистрирован, что происходит, когда Скотт пытается зарегистрировать его снова?Есть ли сценарий, в котором назначение Джейн на проект может быть отклонено?Является ли назначение Джейн в проект единственным ценным результатом?Получает ли она электронное письмо об этом?

Вы, наверное, уже видите, насколько проще использовать конкретные данные при обсуждении сценария.Помните также, что:

  • ведение разговоров важнее, чем
  • захват разговоров , что важнее
  • автоматизация разговоров .

Если вам удастся выполнить все три одновременно, тогда слава, но не идите на компромиссы в разговорах ради автоматизации.

2 голосов
/ 03 апреля 2011

«Персоны пользователя» - очень мощная, но сложная в освоении концепция.Если все сделано правильно, они могут помочь вам упростить и оптимизировать работу пользователей.Сделано неправильно, они занимают время и дают людям в команде субъективные причины кричать друг на друга.

Выезд http://www.agile -ux.com / 2009/12/02 / personas-in-agile-development-yes-we-can / для отправной точки.На эту тему существует масса литературы, хотя в основном она не относится к BDD.

Самый важный совет, который я могу дать, заключается в том, что при определении своих персонажей важно быть очень точным в отношении того, что восхищает / мотивирует /расстраивает их, но эта специфика должна быть с точки зрения мира в целом или вычислений в целом - не привязывайте эти вещи к конкретным аспектам вашего продукта или личным стремлениям к продукту, потому что в противном случае 1) персона быстро устареет и нуждается в нейи 2) люди в конечном итоге будут использоваться в качестве субъективного оружия для продвижения ваших личных устремлений, а не в качестве инструмента, основанного на фактах, для улучшения создания наилучшего продукта для реальных людей.Это гораздо легче сказать, чем сделать.

1 голос
/ 08 октября 2011

Сравните следующее из вашего примера:

Учитывая, что Скотт является руководителем проекта, и проект интеграции stackoverflow никогда не регистрировался в системе. Когда Скотт регистрирует проект интеграции stackoverflow, указав Джейн в качестве участника проекта, тогда проект интеграции stackoverflow должен появиться в списке проектов Джейн

VS:

Учитывая руководителя проекта и незарегистрированный проект, когда менеджер проекта регистрирует проект и указывает члена команды, тогда проект должен появиться в списке проектов члена команды.

Обратите внимание, что формулировка второго примера выше не слишком отличается от первого примера, который вы дали в своем вопросе, но все же немного отличается, так что он выглядит так, как будто он немного более полон. Я думаю, что это то, чего вы, возможно, чувствуете, не хватает, и если бы это было так, я бы отнесся к этому как к «историческому запаху», и если это так, я бы продолжал задавать вопросы и переписывать до история / сценарий кажется более полной.

Лично я нахожу, что использование persona отвлекает меня от поставленной задачи, и мне не нравится заканчивать тем, что мой тестовый код завален текстом, который не читается так, как если бы он принадлежал тому, что я тестирую. Если, с другой стороны, вы используете подход, основанный на данных, и для этой цели определяете какую-то структуру данных, то имеет смысл заполнить эту структуру именами, которые могут иметь смысл в той области, где они тестируются.

Я думаю, что один из рисков при использовании персон - это то, что они иногда могут заменить ленивые имена методов или, что еще хуже, как средство для скучающих программистов, чтобы попытаться внести немного юмора в свой код. Не то, чтобы я думал, что это плохо - развлекаться с вашими именами, но если они не обеспечивают ценность для заинтересованных сторон, то их не следует использовать.

Мне приходит в голову еще одна мысль, что вы можете получить лучшее из обоих миров. Если вы укажете личность своего пользователя в качестве данных для подачи в сценарий вашей истории, вы получите преимущество в том, что ваш код будет чистым и точным, но вы можете сделать вывод более конкретным с точки зрения фактического выполнения теста. Например:

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();
1 голос
/ 03 апреля 2011

хорошо использовать имена для ролей, поскольку они облегчают понимание истории;они больше задействуют ваш мозг приматов, потому что он любит людей и ненавидит абстракцию.Тем не менее, вы должны заботиться!Постарайтесь убедиться, что используемые вами имена не совпадают с именами тех, с кем вы на самом деле работаете - это может быть ужасно запутанно - и не кодируют предрассудки - проект не предубежден, так как не можетесть мнения.Также не используйте одно и то же имя для разных ролей;в то время как реальность может быть беспорядочной смесью с людьми, имеющими много ролей, пользовательские истории не следует путать таким образом, потому что это просто сбивает с толку.

0 голосов
/ 03 апреля 2011

Хотя ваш подход с именованным конкретным пользовательским отсеком будет гораздо проще понять для эксперта по домену (потому что эксперт по домену знает * Scott_the_project_manager * и его задачи), но я думаю, что этот подход нарушает Single_responsibility_principle : OneУ человека могут быть разные роли.

Скотт также может быть вовлечен в маркетинг, а * Magret_the_project_manager * может иметь другие обязанности, чем Скотт

...