Skip to content

Latest commit

 

History

History
92 lines (66 loc) · 7.28 KB

README.md

File metadata and controls

92 lines (66 loc) · 7.28 KB

Разделы

Описание использования в режиме BDD

  • пишем feature-файлы в формате Gherkin
    • обычно используется редактор Visual Studio Code с расширением для Gherkin-файлов
# language: ru

Функционал: Запуск и получение результатов запуска сценариев

Как любой разработчик продукта
Я хочу иметь возможность запустить проверку сценариев поведения на конфигурации 1С:Предприятие

# Контекст сценария выполняется всегда перед каждым сценарием

Контекст:
  Когда существует разрабатываемая мною конфигурация 1С
  И существуют требования заказчика к ожидаемому поведения в каталоге ".\features"

# Каждый сценарий состоит из последовательных связанных шагов

Сценарий: Запуск в консольном режиме
  Дано Пусть существует файл ".\vb-execute-profile.json"
  И в переменную окружения V83PATH установлено значение "C:\Program Files (x86)\1cv8\8.3.6.2151\bin\1cv8.exe"
  Когда я запускаю командную строку '%V83PATH% /Execute .\bddRunner.epf /C"StartFeaturePlayer;VBParams=.\vb-execute-profile.json'
  Тогда появляется файл с результатами '.\BuildStatus.log'
  И в каталоге ".\allurereport" существует HTML отчет о результатах проверки сценариев

Сценарий: Запуск в интерактивном режиме
  Дано Пусть я открыл обработку "bddRunner.epf"
  Когда Я нажал кнопку "Загрузить фичи из каталога"
  И указал каталог ".\features" с требованиями заказчика
  И затем нажал кнопку "Сгенерировать шаблоны обработок"
  Также в каталоге ".\features" возникли epf-файлы, идентичные имени feature файла
  И при нажатии кнопки "Запустить сценарии" я вижу автоматизированный запуск обработок с признаком "pending" (ожидает реализации)

Классический вариант использования (без интерактивного режима)

Фактически классический вариант использования представляет собой следующий рутинный порядок

  • зафиксировали требования к информационной системе
  • создали автоматизированные сценарии проверки в виде feature-файлов
  • наполнили шаги сценариев (сниппеты в виде epf-файлов) кодом проверки поведения
  • запустили сценарии проверки поведения и убедились, что они НЕ работают
  • разработали функционал
  • запустили сценарии проверки поведения
  • убедились, что сценарии проверки работают, и отчет о проверки показывает "Зелёный" статус

Использования в режиме проверки поведения пользовательского интерфейса ("кнопко-нажималки")

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

  • зафиксировали требования к информационной системе
  • создали автоматизированные сценарии проверки в виде feature-файлов
  • разработали управляемые формы или рабочие столы конфигурации в режиме прототипирования
  • запустили запись интерактивных действий пользователя в режиме менеджера тестирования
  • получившимся кодом наполнили обработки проверки поведения в виде epf-файлов
  • дополнили код проверки кодом проверки данных, если это необходимо
  • разработали основной функционал
  • запустили сценарии проверки поведения
  • убедились, что сценарии проверки работают и отчет о проверки показывает "Зелёный" статус

Кто пишет feature-файлы ?

Обратите внимание, что фактически feature-файлы могут писать все участники команды:

  • менеджер проекта - если обнаружил, что заказчику необходимо новое поведение
  • бизнес или системный аналитик - на основе собранных требований и технических заданий
  • ведущий разработки - если обнаружил, что требования недостаточно структурированы
  • архитектор или эксперт 1С - если текущие сценарии некорректно спроектированы с точки зрения метаданных

Для редактирования feature-файлов используется

  • либо Visual Studio Code с расширением для Gherkin-файлов

Если вы не уверены в правильности ожидаемого поведения, используйте для этого системы тэгов, например:

  • "@Draft" - черновик требования
  • "@Предварительно" - начальные заметки

и подобные им обозначения