Огурец Одна функции для нескольких ролей

Question

Как мой вездесущего язык у меня есть какая-то фраза, как:

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 

Это правая пользовательская история? Такие сценарии могут иметь некоторые минимальные различия на уровне пользовательского интерфейса. Должен ли я нарушать DRY principle и повторять эту функцию для другой роли?

Разные пользователи могут нуждаться в разных требованиях с течением времени, и я думаю, что это причина, по которой мы обычно пишем истории пользователей на роль пользователя. Поэтому я должен беспокоиться о том, как требования могут меняться со временем для разных ролей, или я могу уйти один user story (и тот же тестовый код, производственный код, databse ...) с несколькими ролями и refactor, когда их требования заставили меня отделить их?

Answer 1

Я не уверен, в чем проблема, и попытайтесь угадать. Итак, первые три строки - это просто описание, а не реальные шаги. Это позволяет добавлять пользовательский текст, который не будет работать.

Что касается других двух шагов, очень сложно сказать, хороши они или нет. Как вы, возможно, уже заметили, вы не связаны Огурцом, чтобы иметь определенный поток сценариев. Огурец дает вам свободу разрабатывать и писать код так, как это имеет смысл для ВАС и ВАШЕЙ бизнес-логики.

Сказать, что я не вижу проблемы в повторении подобных шагов для проверки другой роли. Чтобы сделать файл свойств немного более сухим, вы можете использовать опцию 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 значение изменяется в соответствии с перечнем примеров.

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

Answer 2

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

Мне кажется, что как администратор, желающий исправить ошибки в сообщении, что мне нужно, чтобы иметь возможность изменить сообщение.

Аналогичная вещь применима к клиенту (должен ли быть автор?). Если вы исследуете, что они будут делать, когда сообщение было автором с ошибкой, вы, вероятно, обнаружите, что разные роли взаимодействуют по-разному. Вы начнете задавать вопросы о том, что произойдет, если клиент и администратор внесут исправления и как реагирует клиент, когда администратор исправляет, что клиент не любит, и всевозможные другие сценарии.

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

Answer 3

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