- Vanessa-ADD ( ADD )
- Введение
- Установка
- Справка и полезные ссылки
- Описание использования
- Подготовка автодокументации
- Описание использования в режиме BDD
- Файлы настройки/профиля запуска обработки
- Создается при финансовой поддержке
- Замечания:
- Известные публикации
- Вдохновение черпается
- Заметки для желающих поучаствовать в доработке
- Лицензии
- Поддержка OpenSource команды
- Простой FAQ по использованию
- Enterprise Support
Продукт Vanessa-ADD (Automation Driven Development) есть набор инструментов для проверки качества решений на платформе 1С:Предприятие.
Vanessa-ADD is a set of testing tools for 1C:Enterprise 8 platform - Tests/behavior (TDD & BDD) for 1С:Enterprise.
Миссия продукта - повышение качества разработки.
Продукт позволяет проверять поведение различных систем на базе 1С и проверяет/гарантирует качество функциональности системы и ее составных частей.
Возможности:
- различные виды тестирования (модульного/юнит, приемочного, сценарного для 1С 8.3, интеграционного, TDD)
- проверка поведения (BDD/Gherkin)
- формирование автодокументации в формате Markdown и видео.
Vanessa-ADD является наследником 2-х продуктов - xUnitFor1C и Vanessa-Behavior. Совместимость с VB 1.Х и xUnitFor1C 4.Х гарантирована.
Порядок установки ADD:
Автоматическая установка (через установщик пакетов OneScript ):
- Выполнить
opm install add
- После выполнения пакет будет установлен в каталог <УстановленныйOneScript>/lib/add
Автоматическая установка (при установке пакета vanessa-runner через установщик пакетов OneScript ):
- Выполнить
opm install vanessa-runner
- После выполнения пакет будет установлен в каталог <УстановленныйOneScript>/lib/add
Ручная установка:
- Перейти в раздел релизы
- Скачать архив
add-x.x.x.zip
с последним стабильным релизом - прямая ссылка Releases - Распаковать указанный архив в нужную папку.
Обязательно ознакомьтесь с:
-
справкой по продукту doc/README.md
-
часто задаваемыми вопросами FAQ.md
-
руководством контрибьютора CONTRIBUTING.md
-
моделью спонсорства DONATIONS.md
-
известными проблемами KNOWN-PROBLEMS.md
Ночная сборка ветки develop:
После установки через opm install
файл продукта расположены по адресу КаталогУстановкиОСкрипт/lib/add
Как правило, в Windows это C:\Program Files (x86)\OneScript\lib\add
.
Возможно тестирование 2-х видов:
- тестирование через фичи, применяя методику BDD (ниже)
- тестирование через код - например, применяя методику TDD
Для каждого из видов тестирования существуют свои браузеры-запускатели тестирования.
- BDD-тестирование -
bddTestRunner.epf
(в корне продукта)- аналогично более раннему проекту
vanessa-behavior
- аналогично более раннему проекту
- тестирование через код -
xddTestRunner.epf
(в корне продукта)- аналогично более раннему проекту
xUnitFor1C
- аналогично более раннему проекту
Возможен как ручной интерактивный запуск тестирования в режиме 1С:Предприятие,
так и автоматический прогон тестирования через командную строку с помощью json-файлов настройки. См. ниже раздел Файлы настройки/профиля запуска обработки
.
Примеры простого и удобного автоматического запуска через Vanessa-Runner
vrunner vanessa --settings tools\vrunner.json
- BDDvrunner xunit --settings tools\vrunner.json
- TDD
Проект использует принцип формирования автодокументации в формате Markdown и видео.
- Видео инструкции лежат здесь
- Прочие инструкции сгруппированы в этом плейлисте YouTube
- Также рекомендуется посмотреть вот этот вебинар
- Возможно, вам поможет этот FAQ
Чтобы у вас работало создание автовидеоинструкций, необходимо установить дополнительный софт.
Инструкция по настройке окружения для формирования автовидеоинструкций здесь. Также по автовидеоинструкциям есть вот это замечательное видео
- пишем feature-файлы в формате Gherkin
- обычно используется редактор Visual Studio Code с расширением для Gherkin-файлов
- или связанный проект vanessa-bdd-editor
# 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-файлы могут писать все участники команды:
- менеджер проекта - если обнаружил, что заказчику необходимо новое поведение
- бизнес или системный аналитик - на основе собранных требований и технических заданий
- ведущий разработки - если обнаружил, что требования недостаточно структурированы
- архитектор или эксперт 1С - если текущие сценарии некорректно спроектированы с точки зрения метаданных
Для редактирования feature-файлов используется
- либо Visual Studio Code с расширением для Gherkin-файлов
- либо проект По автоматизации сбора требований
- на текущий момент имеет статус beta
Если вы не уверены в правильности ожидаемого поведения, используйте для этого системы тэгов, например:
- "@Draft" - черновик требования
- "@Предварительно" - начальные заметки
и подобные им обозначения
Для запуска в консольном режиме используется понятие профиль консольного запуска. Профиль консольного запуска предназначен для удобной передачи параметров. Профиль запуска представляет собой текстовый файл в формате JSON.
Профиль запуска предназначен для простого консольного запуска Пример подобной командной строки выглядит так:
vrunner vanessa --settings tools\vrunner.json
- BDDvrunner xunit --settings tools\vrunner.json
- TDD
Расширенные примеры запуска можно увидеть в соседнем репозитории Vanessa-Runner
или
%V83PATH% /Execute C:\add\bddRunner.epf /C"StartFeaturePlayer;VBParams=C:\VBParams.json"
Текущие параметры настройки для json-файлов:
- Каталог фич - каталог, где собраны требования заказчика описанные на языке Gherkin
- ВыполнитьСценарии - признак того, что необходимо запустить выполнение сценариев
- ДелатьОтчетВФорматеАллюр - признак того, что необходимо формировать HTML отчёт о результатах проверки
- КаталогOutputAllureБазовый - адрес каталога, для где будет формироваться HTML отчёт
- ЗавершитьРаботуСистемы - признак того, что окончанию работы необходимо завершить работу 1С предприятия
- ВыгружатьСтатусВыполненияСценариевВФайл - признак, что необходимо формировать файл с финальным статусом проверки
- ПутьКФайлуДляВыгрузкиСтатуасВыполненияСценариев - по данному пути будет сформирован файл со статусом проверки (обычно используется на серверах сборки для автоматизированного указания статуса сборки)
- СписокТеговИсключение - массив текстовых тэгов для исключения из проверки (например, используется для черновиков сценариев и требований)
- СписокТеговОтбор - массив текстовых тэгов для запуска проверки поведения по сценариям, содержащим любой из указанных тэгов
Пример подобного JSON файла профиля:
{
"КаталогФич": "C:\\add\features",
"ВыполнитьСценарии": "Истина",
"ДелатьОтчетВФорматеАллюр": "Истина",
"КаталогOutputAllureБазовый": "C:\\allurereport",
"ЗавершитьРаботуСистемы": "Истина",
"ВыгружатьСтатусВыполненияСценариевВФайл": "Истина",
"ПутьКФайлуДляВыгрузкиСтатусаВыполненияСценариев": "C:\\BuildStatus.log",
"СписокТеговИсключение":[
"IgnoreOnCIMainBuild",
"Draft"
]
}
Много примеров json-файлов есть в каталоге tools
проекта.
как попасть в этот раздел ? смотри DONATIONS.md
- пожелания к использованию можно фиксировать в виде Github Issues
- структура каталогов проекта соответствует шаблону bootstrap
- мы используем подход git-flow для реализации функциональности
- мы используем принцип самопроверки через feature файлы, поэтому перед разработкой новой функциональности мы также - разрабатываем feature файлы, генерируем шаблоны сценариев и наполняем их кодом для проверки. Поэтому к доработкам без feature файлов мы относимся "холодно".
более подробно в файле CONTRIBUTING.md
- основная лицензия продукта - BSD v3
- лицензии стороннего кода - Apache License, GitHub CLA, Freeware, etc
-
Q: много ли команд используют такой подход ?
-
A: из известных нам - 63 команды
-
Q: можно ли тестировать производительность с помощью BDD ?
-
A: для этого существует другой закрытый инструментарий, который использует vanessa-add как клиента тестирования - используется в Enterprise проектах.
-
Q: Что вы думаете о сценарном тестировании ?
-
A: сценарное тестирование слишком дорого по совокупной стоимости владения, поэтому пусть живет своей жизнью вместе с СППР, обратите внимание, что учебный центр №1 думает провести подготовку слушателей по функционалу тестирования в 1С:Предприятии (ссылка на Facebook - если Вас интересует функционал сценарного тестирования, возможно стоит записаться именно на этот курс, а не ходить по GitHub ссылкам.
-
Q: А где более подробный FAQ
-
**A: Полный FAQ находится в файле F.A.Q.MD.
платная поддержка содержит в себе
- обучение навыкам работы с BDD при разработке на 1С
- обучение навыкам написания на языке Gherkin
- обучение навыкам написания сценариев проверки поведения
для заказа платной поддержки необходимо отравить заявку на адрес education@silverbulleters.org или по телефону +7-(499)-346-70-19.
Контура сборки предоставлены