Может ли один сценарий Gherkin иметь несколько пользовательских ролей?

domain-driven-design bdd gherkin

173 просмотра

3 ответа

1921 Репутация автора

У меня есть следующее:

As an approver #... ?

Scenario : approve a profile
When : I approve a profile
Then : the profile owner should be notified about his profile's approval 
# (on his android device)
And : I should see the profile as a valid profile
And : guests should be able to see the profile

Или я могу сказать:

As an owner

Scenario : approve a profile
When : my profile is approved
Then : I should be notified about my profile's approval
...?

Поскольку my profile is approvedэто событие, оно имеет множество последствий в этом и других ограниченных контекстах.

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

Какие-либо предложения? Заранее спасибо.

Автор: Mohsen Источник Размещён: 18.07.2016 08:51

Ответы (3)


0 плюса

3478 Репутация автора

Используйте сценарий Ouline и на основе некоторых переменных, которые сохраняются при выполнении некоторых действий, вы можете добавить if или переключиться для выполнения проверок.

Автор: lauda Размещён: 20.07.2016 06:52

2 плюса

27677 Репутация автора

Да, совершенно уместно иметь несколько пользователей с разными ролями в одном сценарии. Сценарий корнишона - это сценарий варианта использования; это нормально для случая использования нескольких актеров.

Я бы написал ваш сценарий примерно так:

Scenario: User approves a profile
  Given there is a user "owner"
  And there is a user "approver"
  And there is a user "guest"
  And "owner" has a profile
  When "approver" approves the profile
  Then "owner" should be notified that their profile was approved
  And "approver" should see the profile as a valid profile
  And "guest" should see the profile as a valid profile

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

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

Автор: Dave Schweisguth Размещён: 26.08.2016 03:39

0 плюса

1921 Репутация автора

Решение

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

Попытайтесь решить, что может быть сделано одним разработчиком, а что можно разбить на более мелкие части (поэтому это займет меньше времени).

CQRSНапример, в системе, когда вы используете конечную согласованность (которая должна определяться требованиями), вы можете легко отделить writeтребования gherkinот readтребований gherkin. Но если ваши сценарии требуют немедленной согласованности, вам лучше не отделять сторону чтения gherkinот стороны записи gherkinи позволить одному разработчику (или паре) работать над этим.

И роль пользователя, на мой взгляд, менее важна, но если ваши роли принадлежат к разным BC, вам лучше написать разные gherkinsдля каждого. Истории должны быть независимыми и task prioritizationэто , Product Owner's jobно я предпочел бы приоритеты некоторые из них основаны на технических вопросах.

Автор: Mohsen Размещён: 03.09.2016 06:15
Вопросы из категории :
32x32