Расчёт покрытия кода 1С тестами

Расчёт покрытия кода тестами

Что это и зачем это надо?

Обычным тестированием кода в 1С уже никого не удивишь. Для платформы появились удобные фреймворки тестирования с низким порогом вхождения. Всё больше разработчиков начинает их использовать в своей работе. Некоторые из них настраивают сборочные конвейеры, выгружают результаты в SonarQube. На эту тему написана не одна статья, проведен не один семинар, снято множество видео на youtube. Но практически во всех инструкциях обходится стороной вопрос получения показателей покрытия кода тестами.

Покрытие кода — мера, используемая при тестировании программного обеспечения. Она показывает процент исходного кода программы, который был выполнен в процессе тестирования. © Википедия

Логично предположить что чем выше покрытие кода, тем меньше ошибок должен содержать исходный код.

Любимый 1С-программистами SonarQube умеет показывать покрытие по двум показателям: покрытие строк и покрытие ветвей. Покрытие строк показывает какие строки кода были выполнены при тестировании, а какие нет. Покрытие ветвей вместо строк кода оперирует ветками условных операторов. Например код “Результат = ?(А>0, Б/А, 0);” содержит одну строку, но две ветки, которые мы должны протестировать. К сожалению платформа предоставляет только информацию по выполненным строкам кода, поэтому покрытие ветвей рассматриваться не будет.

Как осуществлялся анализ покрытия раньше?

Попытки сбора данных покрытия предпринимались уже давно. Первая утилита, которую я нашёл на гитхабе была https://github.com/Stepa86/perf-measurements-to-cover Антона Степанова. Принцип её работы очень прост. Он получает на вход файлы замеров производительности 1С, а на выход отдаёт файл формата genericCoverage для загрузки в SonarQube. Проблема заключалась в том что для сохранения файлов замеров производительности приходилось открывать конфигуратор, настраивать автоподключение объектов отладки, запускать замеры производительности, потом останавливать их и сохранять все файлы замеров. При тестировании HTTP-сервисов на каждый запрос создаётся отдельное окно замеров, которое нужно сохранять вручную:

Пару раз сохранив по сотне-другой запросов я принялся искать новый инструмент.

Следующая группа утилит использовала HTTP-отладку, появившуюся в 8.3.7.1759 (https://wonderland.v8.1c.ru/blog/novyy-mekhanizm-otladki/). Это прототип
https://github.com/asosnoviy/onecover-nodeproxy, преемник
https://github.com/ovcharenko-di/1coverage. Оба используют механизм перехвата запросов между сервером отладки dbgs.exe и платформой:

Для этого поднимается прокси-сервер, который сохраняет проходящие через него данные в лог файл, а затем логи конвертируются в один из стандартных форматов. Большинство действий выполняется этими утилитами автоматически, но они также имеют множество проблем. Это и сложность работы с клиент-серверными базами, и невозможность декодирования замеров производительности из бинарного формата.

Можно ли сделать проще?

Да, можно. Я взял библиотеку mdclasses для получения информации о исходниках, выгруженных в xml формат из конфигуратора или EDT, затем добавил проект bsl-parser для получения информации о строках “к покрытию” и подключил несколько библиотек EDT для работы с сервером отладки. Оставалось написать код, реализующий взаимодействие всех этих модулей между собой с целью получения данных о покрытии. Так появился на свет продукт Coverage41C (https://github.com/proDOOMman/Coverage41C), позволяющий выполнять анализ покрытия полностью автоматически и без лишних усилий. Утилита умеет:

• регистрироваться в качестве клиента сервера отладки dbgs.exe;
• подключать все доступные объекты отладки;
• включать замеры производительности;
• конвертировать результаты замеров в формат genericCoverage для SonarQube;
• работать как с файловыми, так и с клиент-серверными базами.

Данный продукт уже некоторое время используется при тестировании проектов 42Облака.

Утилита написана на Java и использует библиотеки EDT, поэтому для её работы в системе должен быть установлены виртуальная машина Java и EDT. Анализируемая информационная база должна использовать HTTP-отладку, поэтому в клиент-серверном варианте потребуется дополнительная настройка. Кроме этого для упрощения развертывания и настройки утилиты в тестовом контуре была создана библиотека шагов, которая умеет запускать сервер отладки, настраивать клиент тестирования на его использование, и запускать анализ покрытия через Coverage41C буквально в несколько строк Gerkin-кода.

Как включить HTTP-отладку в клиент-серверном варианте?

Описание процедуры включения HTTP-отладки доступно на ИТС: https://its.1c.ru/db/v8317doc#bookmark:dev:TI000001604. Для большинства пользователей будет достаточно выполнить повторную регистрацию агента сервера в качестве службы Windows таким образом, чтобы в числе параметров команды ragent был параметр /debug -http:

ragent /instsrvc /debug -http <параметры командной строки>
				

При необходимости, в командной строке регистрации сервера «1С:Предприятия» также можно указать значения параметров /debugServerAddr, /debugServerPort и /debugServerPwd.

После перезапуска агента сервера автоматически запустится сервер отладки dbgs.exe на порту 1550 (или на порту, указанном в параметре /debugServerPort). Убедиться что сервер отладки работает, можно открыв в браузере страницу http://127.0.0.1:1550:

Как включить HTTP-отладку в файловом варианте?

Самый простой способ - включить в конфигураторе отладку по HTTP и запустить клиент из конфигуратора. Такой вариант можно использовать разве что для небольших ручных тестов, т.к. он предполагает выполнение действий пользователем. Для того чтобы автоматизировать подключение отладки для файловой базы, нужно передать определённые параметры командной строки при запуске клиента 1С:

/debug -http /attach /debuggerurl http://127.0.0.1:1999
				

При запуске клиента файловой базы из командной строки, сервер отладки не запускается автоматически. Поэтому dbgs.exe нужно запускать вручную. Его исполняемый файл находится в папке с клиентом 1С предприятия соответствующей версии платформы. Сервер отладки имеет несколько полезных параметров командной строки:

--addr=<host> | -a <host> локальный адрес, на котором будет запущен сервер отладки
				

--port=<port> | -p <port> номер порта, обслуживаемого сервером отладки

--portRange=<range> | -r <range> диапазон портов ("45:49" или "45:67,70:72,77:90") для выбора свободного порта, обслуживаемого сервером отладки
				

--notify=<file name> | -n <file name> имя файла, в который будет записан адрес запущенного сервера отладки, включая номер порта
				

--ownerPID=<owner process ID> | -opid <owner process ID> идентификатор процесса, время жизни которого определяет время жизни сервера отладки
				

Параметры --addr и --port должны совпадать с адресом отладчика, передаваемому в клиент тестирования. Если вы не знаете какой порт будет свободен на момент запуска, можно применить параметры --portRange и --notify. В первый параметр передается диапазон возможных портов, например 1550:1999. Сервер отладки сам выберет свободный порт и запишет свой адрес в файл, указанный в параметре --notify. Параметр --ownerPID нужен для того чтобы не контролировать жизненный цикл сервера отладки. После завершения процесса, PID которого передан в этом параметре, сервер отладки завершится самостоятельно. Если вы используете менеджер/клиент тестирования, то в этом случае вам необходимо включить отладку только в клиенте тестирования. Обратите внимание что регламентные задания также должны выполняться в клиенте тестирования. Для этого менеджер тестирования запускайте с параметрами “/AllowExecuteScheduledJobs -Off”.

Запуск автоматического анализа покрытия

Итак, на компьютере установлены Java и EDT, включена отладка по HTTP в 1С. Теперь можно приступить к анализу покрытия.

Скачиваем и распаковываем последний релиз программы: https://github.com/proDOOMman/Coverage41C/releases

Для проверки работоспособности программы, можно запустить её без аргументов командной строки. Если система настроена корректно, будет выведена справка. Далее можно приступать к тестированию.

• Выгружаем конфигурацию/расширение/внешнюю обработку в файлы (поддерживается как формат EDT, так и конфигуратора);
• Запускаем сервер отладки (только для файловой базы);
• Запускаем сбор данных покрытия командой Coverage41C start с параметрами командной строки:

  -i, --infobase=<infobaseAlias> - имя информационной базы. Для файловых баз можно указать имя DefAlias или вообще не указывать его.
  						

  -u, --debugger=<debugServerUrl> - адрес сервера отладки. По умолчанию - http://127.0.0.1:1550/
  						

  -u:file, --debugger:file=<debugServerUrlFileName> имя файла, в который dbgs.exe записал свой адрес (если вы запускали dbgs.exe с параметром --notify)
  						

  -e, --extensionName=<extensionName> имя расширения, для которого выполняется анализ покрытия. Анализируется ЛИБО конфигурация (параметры -e и -x не указаны), ЛИБО расширение (параметр -e указан, параметр -x не указан), ЛИБО внешняя обработка (параметр -e пустой, -x указан)
  						

  -x, --externalDataProcessor=<externalDataProcessorUrl> URL файла внешней обработки, для которой выполняется анализ покрытия. Имя файла указывается в формате file://D:/path/to/externaldataprocessor.epf
  						

  -P, --projectDir=<projectDirName> путь к директории с проектом
  						

  -s, --srcDir=<srcDirName> путь к исходникам относительно директории проекта
  						

  -r, --removeSupport=<removeSupport> удалить из данных покрытия объекты метаданных “на поддержке”. Параметр необязательный. Поддерживаются значения:
  							NOT_EDITABLE - на поддержке, не редактируется,
  							EDITABLE_SUPPORT_ENABLED - на поддержке с возможностью изменения
  						

  -o, --out=<outputFile>   имя выходного файла в формате genericCoverage

Параметры -P и -s нужны для того чтобы передать в SonarQube корректный относительный путь к исходникам. Например ваши исходники находятся в папке “D:\Path\To\Sources\Project1\src\” и в SonarQube выгружается директория “D:\Path\To\Sources\Project1\”, тогда параметр -P должен быть равен “D:\Path\To\Sources\Project1\”, а -s иметь значение “src”. А если в SonarQube выгружается директория “D:\Path\To\Sources\Project1\src\”, то параметр -P должен содержать полный путь к исходникам “D:\Path\To\Sources\Project1\src\”, а параметр -s можно опустить. Если вы анализируете внешнюю обработку, то указывается путь не к директории с исходниками, а путь к xml (или mdo для EDT) файлу с описанием внешней обработки.

После запуска программа Coverage41C прочитает исходники из указанной директории, подключится к серверу отладки и запустит замеры производительности для всех доступных объектов отладки. На инициализацию потребуется некоторое время, в зависимости от размера исходных кодов. Убедится в завершении инициализации программы можно выполнив в соседнем окне команду Coverage41C check с параметрами -i (имя информационной базы) и -u (или -u:file - адрес сервера отладки). Команда check завершится с кодом 0 после инициализации основной команды. После этого можно начинать тестирование.

Если вы используете BDD-тестирование при помощи инструментов Vanessa-ADD/Vanessa-Automation, в файле VBParams.json нужно прописать отладку по HTTP:

{
					"ЗапускатьТестКлиентВРежимеОтладки": true,
					"АдресОтладчика": "http://127.0.0.1:1550",
					"КлючиОтладки": "-http",
				}
			

Адрес отладчика нужно указывать нужно указывать такой же, как и для остальных инструментов.

После выполнения всех тестов нужно остановить анализ покрытия командой Coverage41C stop с параметрами -i (имя информационной базы) и -u (или -u:file - адрес сервера отладки). Команда stop также дожидается выполнения записи данных покрытия в файл и возвращает код 0 при успешном выполнении.

Далее файл genericCoverage.xml можно передать в SonarQube.

Запуск анализа покрытия с конвертацией

Если на сервере тестирования отсутствуют актуальные исходники тестируемого кода, существует возможность сбора данных покрытия во внутренний формат с последующей конвертацией в стандартный genericCoverage.xml. Для этого при запуске команды Coverage41C start нужно не указывать параметры -P и -s. После завершения анализа, мы получим файл во внутреннем формате, где вместо путей к исходникам будут указаны uuid метаданных. Данный файл можно преобразовать в genericCoverage.xml командой Coverage41C convert. У данной команды параметры аналогичны команде start, за исключением того что параметры подключения к серверу отладки тут отсутствуют и добавлен параметр

 -c, --convertFile=<inputRawXmlFile> имя файла с данными покрытия во внутреннем формате.
			

Работа без установленного EDT

Для работы программы требуются библиотеки EDT com._1c.g5.v8.dt.debug.core_*.jar и com._1c.g5.v8.dt.debug.model_*.jar. Если установить на сервер тестирования EDT полностью затруднительно, то можно скопировать эти библиотеки из папки с установленным EDT и указать путь к ним в переменной окружения EDT_LOCATION.

Передача данных покрытия в SonarQube

Работа с SonarQube описана в других статьях, например https://infostart.ru/public/1089670/. Для передачи данных о покрытии черех sonar-scanner используется параметр -Dsonar.coverageReportPaths:

sonar-scanner.bat -Dsonar.login=TOKEN

-Dsonar.projectName="Project_name"

-Dsonar.projectKey=ProjectKey

-Dsonar.coverageReportPaths=build\genericCoverage.xml

-Dsonar.projectBaseDir=D:\Path\To\Sources\Project1

-Dsonar.sources=src -D"sonar.inclusions=**/*.bsl, **/*.os"

-Dsonar.bsl.languageserver.diagnosticLanguage=ru

-Dsonar.projectVersion=1.0.1.1

В результате в SonarQube мы получим процент покрытия на странице проекта:

Кроме этого будет доступна детализация на странице исходников:

Зелёными отметками выделен код, исполнявшийся при тестировании. Красными - не исполнявшийся код.

Замеры покрытия по сценариям

Утилита поддерживает возможность анализа покрытия в разрезе сценариев. Для этого предназначены команды dump и clean. Команда dump записывает файл покрытия, команда clean очищает информацию о покрытии. Обе команды принимают параметры -i и -u. Таким образом если перед выполнением сценария запустить команду clean, а после выполнения - команду dump, то в файл запишется информация о покрытии исходного кода текущим тестовым сценарием.

Запуск анализа из Vanessa-ADD

Если вам не нравится работать с командной строкой, есть возможность подключить библиотеку шагов для BDD тестирования и управлять анализом покрытия из Gerkin - кода. Библиотека шагов сама скачивает последнюю версию Coverage41C, определяет имя текущей информационной базы и адрес сервера отладки. Библиотека добавляет следующие шаги:

Для корректной работы нужно в первом сценарии или в контексте установить параметры до запуска замеров (имя выходного файла, путь к проекту и исходникам, при необходимости - имя расширения, путь к внешней обработке, пароль, имя ИБ и адрес сервера отладки). Если Coverage41C не установлен в системе глобально, вызываем его установку в каталог проекта командой “я устанавливаю Coverage41C”. Далее запускаем анализ командой “я запускаю анализ покрытия”. Для записи результатов в файл нужно после выполнения последнего сценария вызвать команду “я останавливаю анализ покрытия” либо просто завершить процесс менеджера тестирования. Для файловых баз из кода можно запускать сервер отладки командой “я запускаю сервер отладки (в диапазоне портов)”.

Работа с утилитой из BDD тестов всё также требует наличия в системе Java и EDT. Также нужно указать в файле VBParams.json или в настройках фреймворка тестирования использование HTTP-отладки, либо вызвать шаг “И я настраиваю отладку клиента тестирования”. При запуске сервера отладки в диапазоне портов настройка выполняется без явного вызова шага настройки.

Сохранение результатов покрытия в файл происходит при выполнении команды “Я останавливаю анализ покрытия”, либо “Я сохраняю данные покрытия”, либо после завершения процесса менеджера тестирования.

Сборка утилиты из исходных кодов

Самостоятельная сборка программы из исходников очень проста. Достаточно скачать исходные коды из репозитория https://github.com/proDOOMman/Coverage41C, открыть командную строку, перейти в директорию с исходными кодами и запустить команду “gradlew distZip”. Архив с собранной версией будет находиться в директории build\distributions. Для сборки нужны JDK 11 и EDT.