Критерии принятия (и другие вещи) для истории BDD

Question

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

    Story: execute a workflow
    Scenario: execute a workflow by clicking on execute link in workflow list and nothing goes wrong
    Given I am a user with sufficient rights
    And I have added a workflow called "wf"
    When I click on the execute link next to "wf" in the workflows list
    When I view the list of workflow executions
    Then the output is:
"""
    1 | wf1 | not started
"""

(1-й столбец: элемент №, 2-й: имя рабочего процесса, 3-й: состояние)

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

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

Answer 1

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

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

Story: A doctor diagnoses black death

Scenario: The doctor starts the diagnosis

Given I am doctor with rights to use the system
And I've added a workflow called "diagnosis"
When I choose the "diagnosis" workflow
Then it should tell me that it's not started.

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

Story: A doctor diagnoses Black Death

Scenario: The doctor starts the diagnosis

Given I am doctor with rights to use the system
And I want to diagnose a patient
When I choose "Diagnosis"
Then the system should prompt me to start diagnosing.
Given that all the symptoms match Black Death
When I perform the diagnosis
Then I should be able to diagnose the patient with Black Death.

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

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

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

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

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