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

Code Coverage

Что такое Code Coverage?

Зачем нам нужно Code Coverage?

Начнем с выбора плагина для сборки информации о покрытии кода в одну кучу. Я лично для себя выбрал JaCoCo, который как раз таки собирает информацию о покрытии кода. Но есть и альтернативы.

Сайт JaCoCo предлагает нам скачать плагин, но качать мы нечего не будем, ведь мы используем Build System Maven. Заходим в Maven Repository и ищем JaCoCo Plugin. Берем последнюю версию, и вставляем в наш pom.xml зависимость.

Но через dependencies я делать не рекомендую, ведь есть более хороший, более функциональный альтернативный вариант, и даже не один.

Заходим CodeCov Setup выбираем язык Java и выбираем Using JaCoCo плагин, и ставим по инструкции.

По той же ссылке выбираем Using Maven. Этот вариант будет даже лучше. Cobertura будет извлекать информацию из CI тестов, но увы и тут есть подвох. Все что выше JDK 7 (А на данный момент уже 10 есть) не подойдет. Поэтому мы остановимся на 1 варианте.

В результате в нашем pom.xml должно было появиться что то вроде того:

И в Maven Projects в списке плагинов появится JaCoCo Plugin:

Итак, исходя из Using JaCoCo, нам нужно вписать в наш файл:

Все вроде готово, и остались финальные штрихи. Во-первых давайте скомпилируем наш код, и запустим все тесты, причем сделаем это через Lifecycle Maven:

Так как у нас в плагине JaCoCo стоит фаза выполнения test, то должен был появится отчет после выполнения цикла тестов Maven в папке target:

Подходим к завершению. Мы видим что все работает прекрасно, осталось лишь убедится что это «все прекрасно» также будет работать на внешних источниках. Настала пора собрать все в кучу. Собираем проект и делаем push на GitHub, перед этим открыв Travis CI и Codecov для мониторинга происходящего.

После push мы видим что сборка успешная:

И результат JaCoCo плагина о покрытии кода:

Помните нашу задачу? Да, да, мы забыл про бейджик. Я хотел вынести тему «Украшение» open-source project’ов в отдельную статью, но маленькую часть все же оставлю здесь.

Итак, пошаговая инструкция что бы не заблудится:

Выбираем проект, который вам нужно;

Выбираем Badge и видим ссылки на ваш бейджик в несколько различных формах представления:

Первые это стандартные бейджики, их можно вставить, например, в ваш README.md:

Их особенность в том что при кликании на них вас будет перенаправлять на страницу с отчетом о CC;

Вторые это графы, таблицы и тому подобные штуки:

Источник

Покрытие кода

Что такое покрытие кода?

Покрытие кода — это мера, которая описывает степень тестирования исходного кода программы. Это одна из форм тестирования белого ящика, которая находит области программы, которые не выполняются набором тестовых случаев. Он также создает несколько тестовых случаев для увеличения покрытия и определения количественного показателя покрытия кода.

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

В этом уроке вы узнаете

Зачем использовать покрытие кода?

Вот несколько основных причин использования покрытия кода:

Методы покрытия кода

Ниже приведены основные методы покрытия кода.

Заявление покрытия

Что такое покрытие заявления?

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

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

В White Box Testing тестер концентрируется на том, как работает программное обеспечение. Другими словами, тестер будет концентрироваться на внутренней работе исходного кода, касающегося управляющих потоковых диаграмм или блок-схем.

Давайте разберемся с этим на примере, как рассчитать покрытие выписки.

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

Исходный код:

Сценарий 1:

Операторы, отмеченные желтым цветом, — это те операторы, которые выполняются в соответствии со сценарием.

Количество выполненных выписок = 5, Общее количество выписок = 7

Охват выписки: 5/7 = 71%

Аналогично мы увидим сценарий 2,

Сценарий 2:

Операторы, отмеченные желтым цветом, — это те операторы, которые выполняются согласно сценарию.

Количество выполненных заявлений = 6

Общее количество заявлений = 7

Охват выписки: 6/7 = 85%

Но в целом, если вы видите, все утверждения охватываются 2- м сценарием. Таким образом, мы можем сделать вывод, что общий охват отчетности составляет 100%.

Что входит в покрытие заявления?

Охват решений

Об охвате решений сообщается об истинных или ложных результатах каждого логического выражения. В этом покрытии выражения могут иногда усложняться. Поэтому очень сложно достичь 100% покрытия.

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

Пример покрытия решения

Рассмотрим следующий код:

Сценарий 1:

Код, выделенный желтым цветом, будет выполнен. Здесь «Нет» результат решения If (a> 5) проверяется.

Сценарий 2:

Код, выделенный желтым цветом, будет выполнен. Здесь «Да» результат решения Если (а> 5) проверяется.

Охват филиала

В зоне действия ветки проверяется каждый результат модуля кода. Например, если результаты являются бинарными, вам необходимо протестировать как истинные, так и ложные результаты.

Это помогает вам гарантировать, что каждая возможная ветвь из каждого условия решения выполняется по крайней мере один раз.

Используя метод покрытия Branch, вы также можете измерить долю независимых сегментов кода. Это также поможет вам узнать, какие разделы кода не имеют ветвей.

Формула для расчета покрытия филиала:

Пример покрытия филиала

Чтобы узнать охват ветвей, давайте рассмотрим тот же пример, который использовался ранее

Рассмотрим следующий код

Покрытие филиала также будет учитывать безусловное отделение

Преимущества покрытия филиала:

Тестирование покрытия филиала предлагает следующие преимущества:

Состояние покрытия

Условное покрытие или покрытие выражений покажет, как оцениваются переменные или подвыражения в условном выражении. В этом покрытии рассматриваются только выражения с логическими операндами.

Например, если в выражении есть логические операции, такие как AND, OR, XOR, которые указывают общие возможности.

Условное покрытие обеспечивает лучшую чувствительность к потоку управления, чем покрытие принятия решения. Условие покрытия не дает гарантии о полном покрытии решения

Формула для расчета покрытия условий:

Для приведенного выше выражения у нас есть 4 возможных комбинации

Рассмотрим следующий вход

Состояние покрытия = 25%

Покрытие конечного автомата

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

Какой тип покрытия кода выбрать

Это, безусловно, самый сложный ответ. Чтобы выбрать метод покрытия, тестер должен проверить, что

Чем выше вероятность того, что дефекты повлекут за собой дорогостоящие производственные сбои, тем серьезнее уровень покрытия, который вам нужно выбрать.

Покрытие кода против функционального покрытия

Инструменты покрытия кода

Вот список важных инструментов покрытия кода:

Источник

Автоматизация расчета покрытия кода тестами

Я занимаюсь поддержкой и разработкой технологий для облака 42Clouds. У нас развернуты базы на разделителях, мы используем технологии 1С:Фреш, но немного переделываем их по-своему.

Некоторое время назад мы начитались статей, насмотрелись видео на YouTube и начали активно писать тесты – причем, у нас используются не только сценарные, но и самописные, дымовые тесты.

И в какой-то момент возник вопрос – какого количества тестов достаточно, чтобы наша система была устойчива, в нее можно было легко вносить изменения, не ломая существующую функциональность?

На этот вопрос помогает ответить показатель покрытия кода тестами.

Инструменты, которые отображают покрытие

Что такое покрытие кода и как оно вычисляется? Алгоритмов, чтобы его посчитать, много, мы будем использовать самый простой – покрытие строк.

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

На слайде вы видите простую функцию.

Все строки, которые могут быть выполнены во время теста, помечаются как строки к выполнению – туда не входят комментарии, пустые строки, инструкции препроцессора, директивы компиляции (&НаКлиенте &НаСервере).

Весь остальной код помечается как код к покрытию.

Далее запускаются тесты, и анализируется, какие же строки были выполнены во время тестов.

Результат – процент покрытия, отношение количества строк, которые в ходе тестирования выполнились, к количеству строк, которые должны были выполниться.

Все просто и красиво, но есть проблема. Платформа не предоставляет интерфейс, чтобы посчитать покрытие строк достаточно просто.

Тем не менее, даже в достаточно старых докладах уже встречались варианты, когда покрытие как-то считалось. Но эти механизмы никак не афишировались.

В качестве инструмента для подсчета количества покрытых тестами строк можно использовать SonarQube – здесь на главной странице выводится показатель процента покрытия и множество других метрик кода, которые могут быть подсчитаны благодаря BSL-плагину для SonarQube.

Кроме SonarQube, покрытие можно считать и через другие инструменты – например, через интересный механизм Report Generator, который просто преобразует файл покрытия в HTML-документ, где можно увидеть:

что у нас выполнилось, а что – нет;

процент по разным модулям;

общий процент по проекту.

Например, видно, что некоторые HTTP-сервисы не были покрыты тестами. Хорошо было бы написать тесты, которые проверяют именно их.

Тот же VSCode тоже поддерживает отображение покрытия, для этого есть различные плагины:

Code Coverage Highlighter

Из всех трех лучше всех работал Coverage-Gutters, он на экране. Отмечает красным, что у нас не выполнилось, зеленым – что выполнилось.

То есть отобразить покрытие мы сможем, осталось его добыть.

Анализ файлов замеров производительности

Самый первый шаг в этом направлении сделан путем выгрузки замеров производительности в файлы и дальнейшей их конвертации.

Для выгрузки замеров производительности в файлы существует инструмент https://github.com/Stepa86/perf-measurements-to-cover, написанный на OneScript.

И если в тестируемом решении запускается большое количество фоновых заданий или вызывается HTTP-сервисов – при остановке замера таких окон получится очень много. При этом данные каждого из них нужно сохранять вручную – очень много ручных операций. Посчитать процент можно, но один раз, потом вам это надоест.

Далее появились более продвинутые инструменты, использующие HTTP-отладку, которая появилась в платформе 8.3.7:

поднимают прокси-сервер, который перехватывает вызовы от платформы к серверу отладки dbgs.exe;

ищут в передаваемых данных информацию о замере производительности и пишут ее на диск,

а потом эта информация неким конвертером преобразовывается в один из стандартных форматов покрытия.

Это уже очень крутые инструменты, которые позволяют автоматизировать процесс.

Но при разборе файла покрытия разработчики столкнулись с проблемой так называемого «неизвестного бинаря». Она заключалась в том, что не всегда данные о замерах производительности передавались в текстовом json-формате. Иногда это были бинарные данные, которые расшифровать не получалось – те же фоновые задания в большинстве случаев отправляли данные по замерам производительности в бинарном формате.

Поэтому я решил написать свой инструмент – Coverage41C.

Coverage41C

С инструментом Coverage41C вы можете ознакомиться по адресу https://github.com/proDOOMman/Coverage41C. Он написан на Java, поэтому требует для работы установки JDK 11. В своем составе он использует следующие библиотеки:

MDClasses https://github.com/1c-syntax/mdclasses для разбора исходников конфигурации, выгруженной в файлы в формате как EDT, так и конфигуратора.

BSL Parser https://github.com/1c-syntax/bsl-parser для анализа исходного кода, вычисления строк покрытия.

И некоторые библиотеки, входящие в составе EDT https://edt.1c.ru/. Это самое важное, потому что я обнаружил, что EDT содержит библиотеки, которые позволяют подключаться к серверу отладки dbgs.exe и управлять им – включать замеры, получать данные замеров и их анализировать.

И чтобы с моим инструментом было удобнее работать, в него добавлено немного магии.

По поводу библиотек EDT:

EDT – штука проприетарная, поставляется только по подписке, поэтому я не могу распространять библиотеки для работы с сервером отладки в составе программы. Но есть два варианта обхода ограничений.

Если у вас стоит EDT на компьютере, то никаких действий выполнять не нужно – через утилиту ring автоматом находится путь к установленной EDT, и библиотеки подключаются. Поэтому если у вас есть установленный EDT – вы просто запускаете замеры покрытия и ни о чем не думаете.

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

Если EDT не установлена или переменная окружения EDT_LOCATION не настроена – при использовании Coverage41C будут выданы ошибки.

HTTP-отладчик платформы 1С

Все видели вкладку «Отладка» в конфигураторе, где есть возможность выбора протокола отладки – HTTP или TCP.

Большинство знакомых разработчиков на вопрос «Что такое отладка по HTTP?» отвечают «Мы не знаем». Но здесь смысл здесь в том, что для EDT нужен отдельный протокол отладки, плюс TCP-протокол отладки был не очень красивым – даже разработчики об этом писали – поэтому появился сервер отладки dbgs, который работал по протоколу HTTP. У отладчика dbgs есть много интересных фишек – например, можно отлаживать одну информационную базу из другой. Но это сейчас не главное.

Многие разработчики путают отладку HTTP-сервисов с HTTP-отладчиком dbgs. Говорят, что отлаживают HTTP-сервис, поэтому, наверняка, включена HTTP-отладка. Но это не совсем так: отладку по HTTP нужно включать отдельно.

Далее немного терминологии.

Сервер отладки – это отдельное приложение dbgs.exe, идет в составе платформы.

Объект отладки – то, что мы подключаем в конфигураторе: клиентские приложения, серверный контекст, мобильные приложения.

Интерфейсы отладки – то, что управляет сервисом отладки: либо конфигуратор, либо EDT, либо моя утилита Coverage 41C.

Есть одно ограничение на уровне платформы – одновременно к одной информационной базе может быть подключен только один интерфейс отладки:

Если вы запустите конфигуратор и попытаетесь снять замер покрытия – у вас ничего не выйдет, сервер выдаст ошибку.

И наоборот: если запущен замер покрытия и вы пытаетесь запустить конфигуратор, чтобы в этот момент что-то отладить, конфигуратор скажет, что информационная база уже отлаживается, и ничего не позволит сделать.

Включаем HTTP-отладку

Как же включить HTTP-отладку?

Если у вас файловая информационная база. Когда вы хотите отлаживать файловую информационную базу через HTTP в конфигураторе – вы меняете в настройках отладку на HTTP и запускаете приложение. В этот момент конфигуратор сам запускает dbgs.exe и держит его запущенным, пока запущено клиентское приложение.

При запуске Coverage41C мы конфигуратор не используем, поэтому dbgs.exe мы должны запустить вручную – файл dbgs.exe лежит в папке с платформой:

в качестве аргумента получает порт, на котором будет запущен (-p 1559).

второй вариант запуска – в диапазоне портов в первом свободном порте (-r 1560:1591).

Мы для простоты используем вариант с указанием порта – запускаем dbgs.exe, и он ждет, когда мы подключим клиентское приложение.

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

Чтобы проверить, что сервер отладки действительно запустился – мы адрес отладчика можем открыть в браузере. Он выведет нам, что все работает – it works!

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

GenericCoverage – используется для SonarQube

Lcov.info – для VSCode, ReportGenerator и т.д., возможности применения такого формата гораздо шире.

Они отличаются: GenericCoverage – xml-формат, Lcov.info – просто текстовый формат.

Тем не менее, SonarQube любим одинэсниками, поэтому по умолчанию покрытие выводится в формате GenericCoverage.

Интерфейс командной строки

Утилита представляет собой консольное приложение. Интерфейс не слишком сложный.

Есть основные команды:

Для самого простого варианта вам нужна лишь команда start, которая запускает анализ покрытия. На ней мы остановимся подробнее, что вообще с ее помощью можно сделать.

Основные параметры команды start – имя информационной базы и адрес отладчика. По этим параметрам подключается замер покрытия к серверу отладки.

Если у вас серверная информационная база – имя информационной базы такое же, как в кластере.

Если у вас файловая информационная база, то имя информационной базы будет DefAlias. Можете почитать на ИТС – это имя по умолчанию для любой файловой базы.

Мы можем измерять либо покрытие тестами кода конфигурации, либо расширения, либо внешней обработки – что-то одно. Совместные замеры пока не реализованы. Если это кому-то нужно – пишите, что-нибудь придумаем.

Если вы хотите замерить покрытие конфигурации – никаких лишних флагов не нужно, измеряется по умолчанию.

Также нам нужны будут два флага – путь к исходникам конфигурации и путь к директории проекта. Для большинства проектов достаточно задать только путь к исходникам:

В случае формата EDT ничего распаковывать не нужно – у нас уже все есть.

В случае формата конфигуратора просто выгружаете ваш проект в файлы.

Примеры использования команды start.

Измерение покрытия кода для конфигурации в файловой базе:

Измерение покрытия кода конфигурации в серверной базе с вырезанием кода на замке – имя конфигурации меняется, меняется адрес отладчика, и добавляется, что мы вырезаем код на замке:

Покрытие для кода расширения – добавляется имя расширения:

Покрытие для кода внешней обработки.

Далее команды stop, dump, clean.

Stop – останавливает замеры покрытия кода и записывает файл на диск.

Dump пишет текущее состояние на диск.

Clean очищает информацию о выполненных строках кода в запущенном экземпляре программы.

Эти команды принимают аргументы: имя информационной базы и имя отладчика. По связке этих двух параметров ищется экземпляр Coverage41C, в который передаются эти команды.

Также команда stop нужна для пайплайнов или скриптов – если хотите прервать команду start, запущенную в консоли, вручную, просто нажмите Ctrl+C. Тогда будет корректное завершение с записью всей информации на диск.

Есть еще команда convert – некоторые по привычке пытаются ее использовать всегда, это уже замечено на GitHub в сообщениях об ошибках.

Суть в том, что все предыдущие инструменты требовали конвертации данных: сначала шел сбор данных, затем – конвертация. Здесь, если мы передали путь к исходникам, конвертация не нужна – на выходе мы получаем файл нужного формата, который можно использовать.

Но если на сервере, где вы проводите тесты, нет исходников – допустим, их неудобно туда тащить – тогда вы команде start не передаете путь к исходникам, и данные в выходном файле будут записаны во внутреннем формате, где вместо путей к файлам указаны идентификаторы метаданных. Такой файл вы можете передать обратно – на компьютер, где распакованы исходники вашего проекта, и сконвертировать его в нужный вам формат с помощью команды convert.

У команды convert есть:

Интеграция с Vanessa-ADD/Vanessa-automation

Возможно, кто-то скажет, что работать с программой через консоль сложно и непонятно, лучше сделать проще: например, написать графический интерфейс. Не надо этого делать.

Если вы используете BDD-тестирование – Vanessa-ADD или Vanessa-automation – вы можете скачать библиотеку шагов, которая находится в дебрях моего репозитория по ссылке https://github.com/proDOOMman/Coverage41C/blob/master/src/test/resources/bdd/features/step_definitions/Coverage41C.epf.

Эту обработку нужно положить в папку step_definitions каталога с вашими фичами или каталога библиотек Vanessa, и после обновления кэша шагов у вас появятся готовые шаги.

В принципе, библиотека шагов повторяет весь консольный интерфейс программы, но дополнительно есть несколько полезностей.

Например, вы можете прямо из кода Gherkin запускать сервер отладки – для этого есть два шага: «И я запускаю сервер отладки» или «И я запускаю сервер отладки в диапазоне портов». На файловых базах я рекомендую вам использовать второй шаг с указанием, на каких портах вы можете запустить dbgs.

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

Для установки Coverage41C есть три варианта:

Либо вы просто скачиваете с GitHub последний релиз и его распаковываете – это обычный zip-архив.

Либо используете пакетный менеджер Chocolatey с командой «choco install Coverage41C». Но там, возможно, не всегда будут актуальные версии, потому что модерация на Chocolatey очень длительная.

И третий вариант – использовать шаг «И я устанавливаю Coverage41C». В этом случае также с GitHub скачивается последняя версия и устанавливается в каталог проекта.

У библиотеки шагов те же возможности, что и в консольной утилите. Например, есть шаг «И я устанавливаю имя ИБ для анализа покрытия» и другие.

Имя информационной базы также вычисляется автоматически при шаге «И я настраиваю отладку клиента тестирования» или «И я запускаю сервер отладки» – любой из этих шагов автоматически определяет имя текущей информационной базы и автоматически заносит его в настройки Coverage41C.

Для того, чтобы запустить замер покрытия с помощью библиотеки шагов Gherkin, вам нужно всего лишь пять шагов:

И я запускаю сервер отладки

И я устанавливаю Coverage41C;

И я устанавливаю путь к проекту для анализа покрытия (или «И я устанавливаю путь к исходникам для анализа покрытия»)

И я устанавливаю имя выходного файла анализа покрытия

И я запускаю анализ покрытия.

Анализ покрытия завершится автоматически после закрытия менеджера тестирования.

Если вы для запуска тестирования используете тот же Vanessa-runner – он автоматом может закрывать менеджер тестирования. После этого замеры завершаются, сохраняются на диск, и после этого вы можете их использовать.

Возможна небольшая пауза, потому что запись на диск займет какое-то время, особенно на больших проектах.

Работа Coverage41C в режиме реального времени

У меня есть маленькая база, на которой я покажу, как можно организовать BDD-тестирование с покрытием, используя предложенную библиотеку шагов.

папка с файловой информационной базой – база очень простая и содержит только одну обработку, которую мы и будем тестировать;

папка с ее распакованными исходниками;

и папка, где лежит фича и рядом с ней в подпапке step_definitions находится библиотека шагов Coverage41C.epf.

Vanessa запустилась, нажимаем «Выполнить сценарий». Запускается клиент тестирования – сейчас будет запущена наша обработка, которая выведет «Привет, Infostart». В коде обработки есть одно условие, которое в зависимости от входных параметров пойдет либо по одной ветке, либо по другой.

Итак, тестирование закончено, все закрываем и смотрим папку с исходниками.

В результате тестирования в папке с исходниками появился файл genericCoverage.xml.

В нем у нас указаны строки покрытия – видно, что есть три строки, из которых две были выполнены.

Запускаем сканирование проекта и посмотрим на результат. Итак, покрытие 66,7%.

Вот так выглядит покрытие – зеленым покрытые, а красным – непокрытые строки.

На этом прощаюсь: заходите на GitHub https://github.com/proDOOMman/Coverage41C, оставляйте сообщения об ошибках и пожелания – все учтем. Спасибо за внимание.

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе «DevOps в 1С: Тестирование и контроль качества решений на 1С». Больше статей можно прочитать здесь.

Источник