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

Question

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

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

Answer 1

@ MrWiggles
как сказал t0rx, вам повезло иметь QA для написания историй / сценариев.
Подходя к вашему вопросу:
Поведенческая разработка побуждает вас начинать определять истории с помощью сценариев, выражающих желаемое поведение в текстовом формате.
JBehave Stories вы можете запустить, настроив в 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 на данном этапе сборки

Answer 2

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

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

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