Тестирование

Прогоны идут по очереди: информационная база одна.

Расширение интегрирует тесты 1С с нативной панелью Тестирование VS Code (Test Explorer): дерево тестов с иерархией каталогов, кнопки запуска в редакторе, зелёные/красные статусы и переход к месту падения.

Поддерживаемые фреймворки

Фреймворк	Что в дереве	Откуда берутся настройки и результаты
Vanessa Automation	.feature → сценарии	настройки VA проекта; отчёт jUnit или Cucumber JSON
xUnit / Vanessa-ADD	исходники тестовых обработок → методы (обработка собирается перед прогоном)	активный профиль запуска, секция xunit
YAxUnit	модули тестового расширения → тесты	активный профиль запуска, секция yaxunit; tools/yaxunit.json
OneScript (1testrunner)	.os-тесты с ИсполняемыеСценарии или аннотациями &Тест	отчёт в build/out/onescript
OneScript (OneUnit)	.os-тесты, в том числе &ПараметризованныйТест	отчёт в build/out/onescript
1bdd	.feature в OneScript-проектах	отчёт в build/out/1bdd

Раннер OneScript выбирается настройкой test.onescriptRunner: по умолчанию auto — OneUnit, если он установлен в проекте или объявлен в packagedef, иначе 1testrunner. Путь к раннеру можно задать явно настройкой test.onescriptRunnerPath.

Все фреймворки включены по умолчанию; состав можно менять командой Настроить тесты (кнопка «Настроить тесты 1С» в пустой панели тестирования) или настройками 1c-platform-tools.test.frameworks.*. Каталог фич принадлежит Vanessa в проектах 1С (есть выгрузка конфигуратора или проект EDT) и 1bdd — в OneScript-библиотеках. Файлы .os — всегда OneScript: тесты для 1С (xUnit) существуют только как внешние обработки.

Точечный запуск отдельного теста поддерживают YAxUnit, OneScript и 1bdd. У Vanessa Automation и xUnit запускается файл целиком — статусы всех его кейсов обновляются из отчёта.

Выполняется то, что выбрано. Запустить можно файл, каталог и весь набор; выполнятся ровно выбранные тесты.

Где фреймворк умеет прогнать несколько файлов за раз, набор идёт одним сеансом 1С вместо сеанса на файл, а результаты общего отчёта расходятся по файлам дерева. У Vanessa Automation одним сеансом идут весь набор и каталог целиком: --feature-path принимает один путь. Произвольная россыпь файлов прогоняется поштучно.

Параметризованные тесты OneUnit (&ПараметризованныйТест + &ИсточникЗначение) разворачиваются в отдельный кейс на каждый набор значений; имя кейса совпадает с отчётом (по умолчанию [значение], напр. [ibcmd]). Точечный запуск такого кейса выполняет процедуру целиком (раннер прогоняет все её наборы значений). Наборы значений из &ИсточникJSON/&ИсточникВыражение/&ИсточникПеречисление известны только в рантайме — такой тест показывается одним кейсом по имени метода. Когда несколько процедур в файле дают одинаковые метки ([ibcmd] у обеих), рядом с кейсом подписывается имя процедуры, и результаты сопоставляются с учётом контейнера.

Структура каталогов тестов

project/
├── build/out/tests/
│   ├── cfe/                # СОБРАННЫЕ тестовые *.cfe (артефакт, не в git)
│   └── epf/                # СОБРАННЫЕ .epf тестов 1С (артефакт, не в git)
├── features/               # Сценарии Gherkin (Vanessa Automation / 1bdd)
└── tests/                  # Скриптовые тесты OneScript (*.os)
    ├── cfe/                # ИСХОДНИКИ тестовых расширений (YAxUnit и тесты)
    └── epf/                # ИСХОДНИКИ тестовых обработок 1С (формат decompileepf)

Граница простая: в src лежит поставляемое решение, всё нужное только для прогона - в tests.

• tests/ — скриптовые тесты OneScript (1testrunner/OneUnit). Бинарники тестов здесь не хранятся: дымовые наборы Vanessa-ADD поставляются в составе пакета add (oscript_modules/add/tests/smoke);
• tests/epf/ — исходники тестовых обработок 1С, по подкаталогу на обработку: выгрузка конфигуратора или проект 1С:EDT. Панель тестирования показывает методы прямо из исходника и собирает обработку перед прогоном (неизменённые обработки не пересобираются);
• tests/cfe/ — исходники тестовых расширений, см. Тестовые расширения;
• build/out/tests/ — собранные артефакты тестов: .epf в epf, *.cfe в cfe. В git не попадают.

Каталоги тестовых расширений и обработок настройками не задаются: расширение находит их само, а тестовыми их делает каталог тестов в пути, см. Раскладка проекта. Имя каталога задаёт test.directoryName, по умолчанию tests. Скриптовые тесты *.os лежат в нём же, другой каталог для них задаёт test.path.onescriptTests.

Команды сборки unit-тестов

• Собрать unit-тесты — собирает тестовые обработки из исходного кода tests/epf в build/out/tests/epf.
• Разобрать unit-тесты — раскладывает хранимые .epf в исходный код: удобно для первичного переноса тестов под контроль версий.

Обе команды доступны в дереве 1С: Инструменты (группа «Тестовое окружение», рядом с командами тестовых расширений) и в палитре команд (F1 → «1С: Тестирование → Собрать unit-тесты»). Отдельно вызывать сборку не требуется: панель тестирования собирает обработку перед прогоном сама.

Настройки прогонов

Расширение использует служебные файлы проекта и не генерирует свои. Все прогоны идут под активным профилем запуска: его --settings подставляется централизованно, а пути отчётов и параметров читаются из файла профиля с учётом схемы (плоские секции в env.json, каскад vrunner.test.* в autumn-properties.json).

• профиль — секции vanessa (vanessasettings), xunit (reportsxunit — отсюда берётся путь jUnit-отчёта) и yaxunit (см. ниже);
• tools/VAParams.json — какие отчёты пишет Vanessa Automation (jUnit или Cucumber JSON) и куда;
• tools/yaxunit.json — базовый конфиг RunUnitTests; панель накладывает на него фильтр по выбранному модулю/тесту.

Если конфиги не настроены, используются временные настройки с отчётом в test.reportsPath.

Настройки

Настройка	По умолчанию	Описание
test.enabled	true	Интеграция с панелью тестирования
test.featuresPath	features	Сценарии Gherkin
test.directoryName	tests	Имя каталога тестов
test.path.onescriptTests	каталог тестов	Каталог скриптовых тестов *.os
test.frameworks.*	включены	Включение фреймворков (через «Настроить тесты»)
test.exclude	["oscript_modules", "build"]	Сегменты пути, исключаемые при поиске тестов
test.onescriptRunner	auto	Раннер OneScript: auto / 1testrunner / oneunit
test.path.onescriptRunner, test.path.onebdd	—	Пути к раннерам (поддерживают относительные)
test.path.yaxunitConfig	tools/yaxunit.json	Базовый конфиг YAxUnit
test.path.reports	build/out/testapi	Временные файлы прогонов

Тестовые расширения

Расширения, нужные только для прогона, живут отдельно от решения: исходники в tests/cfe, на каждое - подкаталог с именем расширения. Туда же ставится YAxUnit, удобнее всего сабмодулем: тогда он обновляется своим релизным циклом и не смешивается с кодом продукта.

В дереве метаданных тестовые расширения видны наравне с остальными.

Команды - в группе «Тестовое окружение», рядом со сборкой и разборкой unit тестов: там собрано всё, чем тестируют, а «Расширения» и «Внешние файлы» остаются про поставку. Запуск тестов - в группе «Тестирование».

Команда	Что делает
Загрузить тестовые расширения из исходного кода	Грузит их в базу из исходного кода и обновляет конфигурацию БД
Выгрузить тестовые расширения в исходный код	Выгружает установленные расширения из базы в исходный код
Собрать тестовые *.cfe из исходного кода	Собирает *.cfe в build/out/tests/cfe
Разобрать тестовые *.cfe в исходный код	Раскладывает *.cfe из build/out/tests/cfe в исходный код

Имя расширения берётся из его Configuration.xml, а не из имени каталога: в tests/cfe/yaxunit-test лежит расширение Тесты, и в базу оно уходит под своим именем.

Разбирается сам файл, а не установленное в базе: так подключают полученный со стороны YAxUnit.cfe - положить его в build/out/tests/cfe и разобрать в tests/cfe/<имя>.

Все четыре показывают выбор расширений с флажками: можно подключить только YAxUnit, только своё расширение с тестами или оба сразу. Выбор запоминается для проекта отдельно от выбора расширений решения. Чтобы окно выбора не показывалось, перечислите нужные расширения в 1c-platform-tools.test.cfe.selected. Агент передаёт выбор параметром extensions.

Собранные *.cfe кладутся в build/out/tests/cfe, отдельно от расширений решения: команда «Загрузить расширения из *.cfe» берёт только их каталог и тестовые в базу не потянет.

Фильтр прогона YAxUnit строится по тому расширению, которому принадлежит запускаемый модуль: имя берётся из его Configuration.xml, а список filter.extensions из tools/yaxunit.json для прогона из панели не ограничивает - иначе тест из другого расширения дал бы пустой отчёт.

Панель тестирования ищет тесты YAxUnit и в расширениях решения, и в тестовых: расширение с тестами встречается и внутри решения, и рядом с тестами. Отладчику каталоги тестовых расширений тоже передаются, иначе в тест нельзя было бы зайти точкой останова.

YAxUnit и профиль запуска

Секция yaxunit профиля задаёт запуск тестов YAxUnit из панели и командой «YAxUnit тесты»: конфиг в --command (RunUnitTests=<конфиг>) вместо настройки test.path.yaxunitConfig, режим клиента --ordinaryapp, файл кода возврата --exitCodePath, а также --additional и --no-wait. Так разные профили запускают разные конфиги, например дымовой и полный. Секция добавляется в редакторе профиля и при создании файла настроек.

В autumn-properties.json это секция vrunner.test.yaxunit с опциями команды vrunner test yaxunit: готовый конфиг yaxunit-config, отчёт report, файл кода возврата exitcode, фильтры ext, modules, tests, tags и suites. Готовый конфиг используется как есть, поэтому отчёт, код возврата и фильтры из секции действуют, когда конфиг не задан.

Особенности

• Прогоны выполняются последовательно — информационная база одна.
• Отмена прогона завершает всё дерево процессов (включая 1cv8).
• Команды группы «Тестирование» в дереве инструментов (XUnit, Vanessa, YAxUnit, синтаксический контроль, Allure) остаются способом запуска «всего сразу».
• Allure отчёт собирает результаты всех фреймворков: каталоги берутся из настроек проекта (секции xunit и syntax-check, файл настроек VA, конфиг YAxUnit) и дополняются обходом build/out, где лежат прогоны из панели. Дубли одного прогона в двух форматах отбрасываются. Самой команде Allure нужна Java в системе: portable JRE расширения достаётся только дереву метаданных.

Синтаксический контроль в панели Problems

Ошибки vrunner syntax-check собираются в панель Problems и подсвечиваются в файлах модулей.

• Источник — jUnit-отчёт прогона; путь берётся из файла активного профиля запуска (схемо-независимо: секция syntax-check / каскад vrunner.validate.syntax-check, опция junitpath), с откатом на build/out/syntax-check/junit/junit.xml.
• Обновление автоматическое: расширение следит за файлом отчёта и перечитывает его после каждого прогона (повторный прогон обновляет/очищает диагностику). Смена активного профиля или правка его env-файла пересобирают путь к отчёту.
• Путь по метаданным из отчёта (ОбщийМодуль.Имя.Модуль) сопоставляется с файлом .bsl в выгрузке конфигурации. Записи, не раскладывающиеся в модуль (справка, неизвестные типы), собираются на Configuration.xml с указанием пути в тексте.
• Номера строк vrunner не выдаёт, поэтому позиция ищется по идентификатору метода из текста ошибки (например "Существует"): каждое вхождение в модуле подсвечивается отдельно. Если идентификатор не извлечь/не найти — ошибка ставится в начало файла.
• Команды палитры: 1С: Тестирование → Обновить ошибки в Problems и … → Очистить ошибки в Problems. Ручное обновление полезно, если каталог build исключён из слежения (files.watcherExclude) и автоматическое обновление не срабатывает.