Организация историй JBehave

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

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


person tddmonkey    schedule 29.10.2010    source источник
comment
Извиняюсь за это - я только что увидел пузырек уведомлений, который говорит мне, что у меня есть ответы. Смущенный.   -  person tddmonkey    schedule 14.12.2012
comment
Это весело, а не проблема, MrWiggles   -  person Ripon Al Wasim    schedule 14.12.2012


Ответы (2)


@MrWiggles
как сказал t0rx, вам повезло, что у вас есть QA для написания историй/сценариев.
переходя к вашему вопросу:
Разработка, ориентированная на поведение, призывает вас начать определять истории через сценарии, которые выражают желаемое поведение в текстовом формате.
Истории JBehave можно запустить, настроив в Maven (pom.xml).

Вы можете создать папку для хранения ваших файлов истории в структуре вашего пакета, как показано ниже:

Your_Project
      |
      |
      |--Source_Code
      |
      |--Stories
      |
      |--Testing
      |
      *pom.xml

Настроив свои истории в maven, каждый раз, когда вы создаете проект, он будет давать результаты с успешными и неудачными историями/сценариями.
QA обновит сценарии в папке Stories, а разработчик будет реализовывать сценарии шаг за шагом. опуская существующие шаги (которые уже разработаны и пришли в других сценариях).
QA просто запускает сценарий/историю, и он узнает результат в текстовом (понятном) формате.
Как показано ниже: введите здесь описание изображения

Разработка, основанная на поведении, на тестовых уровнях. введите здесь описание изображения

Некоторые функции JBehave сосредоточены на простоте организации.

  • Конфигурация на основе аннотаций и спецификации класса Steps
  • Поддержка внедрения зависимостей, позволяющая создавать экземпляры конфигурации и шагов с помощью вашего любимого контейнера (Guice, PicoContainer, Spring).
  • Расширяемые отчеты по историям: выводит истории, выполненные в различных удобочитаемых файловых форматах (HTML, TXT, XML). Полностью стильный вид.
  • Автоматическое создание ожидающих шагов, поэтому сборка не прерывается из-за отсутствующего шага, но есть возможность настроить прерывание сборки для ожидающих шагов.
  • Локализация пользовательских историй, позволяющая писать их на любом языке.
  • Интеграция с IDE: истории можно запускать как JUnit тесты или другие среды модульных тестов на основе аннотаций, что обеспечивает простую интеграцию с вашей любимой IDE.
  • Интеграция с Ant: позволяет запускать истории с помощью задачи Ant.
  • Интеграция с Maven: позволяет запускать истории через плагин Maven на данном этапе сборки.
person Chandra Sekhar    schedule 26.12.2011

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

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

Альтернативный подход заключается в том, что QA/владелец продукта отправляет сценарии разработчикам, которые затем очищают их перед добавлением в систему управления версиями, но это возвращает усилия разработчиков.

person t0rx    schedule 20.11.2010