Как вы фиксируете требования с помощью декларативных приемочных испытаний?

Question

Фон

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

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

Мы определяем критерии приемки как список правил (например, проверка входных данных, значения по умолчанию и т. Д.), А приемочные испытания - как список сценариев огурца. Мы планируем использовать Calabash для мобильного тестирования.

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

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

проблема

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

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

Возможно, я присвоил термин " приемочные испытания". В моем случае приемочный тест не соответствует уровню юнит-теста. Я рассматриваю приемочный тест как интеграционный тест высокого уровня.

Пример

• Как гость
• Я хочу войти
• для доступа к функциональности приложения

Императивный тест

• Сценарий: действительный логин
  • Учитывая, что я нахожусь на экране "входа в систему"
  • Когда я ввожу "[e-mail]" в "электронная почта"
    • И я ввожу "password1" в "пароль"
    • И я нажимаю "войти"
  • Затем я вижу "Войти успешно"

Декларативный тест

• Сценарий: действительный логин
  • Учитывая, что у меня есть действующий аккаунт
  • Тогда я могу войти

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

Вопрос

Как вы фиксируете требования для функции с декларативными шагами?

Answer 1

Красиво написанный вопрос!

Как вы фиксируете требования для функции с декларативными шагами?

Требования к функции записаны в определениях шагов.

Следовательно, в вашем императивном примере:

When I enter "[e-mail]" in "email"
And I enter "password1" in "password"
And I tap "login"

это можно сделать декларативным, переписав его так:

Given I login using valid credentials

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

Given I login using invalid credentials

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

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

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

"Лошади на курсы!"

Будет очень интересно увидеть другие ответы на этот вопрос от сообщества SO.

Answer 2

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

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

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

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

Feature: Delivery 
    Free delivery is offered to customers who order two or more items

  Scenario Outline: Calculate postage for delivery
    Given I am signed-in
    When I "<order>" items
    Then postage should be "<postage>"   

    Examples:
    | order | postage |
    | 1     | 0.99    |
    | 2     | 0       |
    | 3     | 0       |
    | 0     | ?       |

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