Здравствуйте, товарищи программисты и все кто им сочувствует. Я хотел бы предложить обзор возможностей сборочной системы QBS для интеграции покрытия кода в Qt автотесты QtTest с использованием утилит gcov/lcov. Кому эта тема интересна, добро пожаловать по кат.
Итак, давайте разберемся, что означает термин "покрытие кода". Вкратце, это когда используется некая утилита (или комплекс ПО) которая позволяет отследить и отобразить в той или иной форме результаты того, насколько тот или иной автотест покрывает исходный код чего-либо.
Обычно, эта утилита встраивает часть некоего своего кода (например, в виде библиотеки, слинкованной с автотестом) для генерации дополнительной информации в процессе работы автотеста. При этом, полученную информацию можно отобразить в любой удобной форме (обычно это HTML страницы).
Содержимое этой информации включает процентное соотношение количества строк и ветвей кода, обработанных автотестом, а также полную информацию о состоянии всех строк и ветвей.
Что мы будем использовать
В нашем текущем примере мы будем идти по пути "наименьшего сопротивления" и использовать общедоступное и свободное ПО (т.к. мы все в душе лентяи):
Компонент | Что это такое | Причина выбора |
Операционная система. | Доступность, бесплатность, простота. | |
Набор компиляторов. | Доступность, бесплатность, простота. | |
Утилита, собирающая предварительную информацию о покрытии. | Уже содержится в наборе компиляторов GCC. | |
Утилита конвертирующая результаты покрытия в удобной форме. | Доступность, бесплатность, простота. | |
Утилита конвертирующая результаты покрытия в HTML формат (входит в состав lcov). | Доступность, бесплатность, простота. | |
Кросс-платформенный С++ фреймворк. | Доступность, бесплатность, простота. Уже содержит свой собственный тестовый фреймворк QtTest. | |
Кросс-платформенное и универсальное IDE. | Доступность, бесплатность, простота. Поддерживает автотесты QtTest и сборочную систему QBS "из коробки". | |
Кросс-платформенная система сборки. | Доступность, бесплатность, простота, модерн и удобство (да и вообще, няшка). |
Примечание: Я здесь не буду расписывать как устанавливать те или иные пакеты, т.к. считаем, что пользователь разберется сам (например, погуглит).
Как работает GCOV/LCOV
Вкратце, чтобы включить поддержку покрытия кода в автотестах, используя компилятор GCC (или CLang), достаточно собрать приложение с отключенной оптимизацией (чтобы компилятор не выкидывал секции, ветвления и т.д., а оставлял "как есть") и передать ему флаг --coverage как в опции компилятора так и в опции линковщика.
Примечание: Именно так и никак иначе, т.к.приложение автотеста просто не скомпилируется.
При этом, линковщик автоматически слинкует с исполняемым приложением автотеста некий дополнительный код, который будет заниматься сбором информации об использованных строках и ветвях в коде (я так предполагаю).
Все это хозяйство заработает только после реального запуска приложения автотеста. По завершению работы приложения автотеста будет автоматически сгенерирован бинарный файл с результатами покрытия в специальном формате.
Далее, этот выходной файл результатов покрытия можно передать, например, утилите lcov для генерации "дружелюбной" информации для пользователя. Например, как набор красивых HTML страниц с подробной информацией о покрытии.
Какие нужны шаги
Ниже приведу минимальный список шагов что и как мы будем делать для достижения результата:
Пишем некий код, который надо проверить.
Пишем некий автотест который линкуется с кодом и проверяет его.
Запускаем автотест и проверяем что он работает.
Добавляем опцию
--coverageпри сборке автотеста.Запускаем автотест и проверяем что он сгенерировал выходную информацию о покрытии в выходной файл.
Передаем сгенерированный выходной файл в утилиту lcov для генерации красивых результатов в HTML формате.
Открываем HTML результаты и любуемся.
ШАГ1. Создаем проект и пишем код
Давайте для простоты создадим простейшее дерево проекта COVERAGE-EXAMPLE со следующей структурой:
COVERAGE-EXAMPLE
│ .gitignore
│ coverage-example.qbs
│
├───src
│ │ src.qbs
│ │
│ └───libs
│ │ libs.qbs
│ │
│ └───foo
│ foo.cpp
│ foo.h
│ foo.qbs, где:
coverage-example.qbs- это корневой файл проекта:
Project {
name: "coverage-example" // Задаем уникальное имя корневого проекта.
references: [
"src/src.qbs", // Подключаем директорию с исходниками в проект.
]
}src/- директория содержащая исходные коды под-проекты главного проекта, которые перечислены в файлеsrc.qbs(в нашем случае это будут только под-проекты библиотек):
Project {
name: "sources" // Задаем уникальное имя под-проекта общих исходников.
references: [
"libs/libs.qbs" // Подключаем директорию с исходниками библиотек в проект.
]
}libs/- директория содержащая исходные коды под-проектов библиотек, которые перечислены в файлеlibs.qbs(в нашем случае это будет только один продукт библиотекиfoo):
Project {
name: "libs" // Задаем уникальное имя для под-проектов библиотек.
references: [
"foo/foo.qbs" // Добавляем директорию с исходниками библиотеки 'foo' в проект.
]
} libs/foo/- директория содержащая исходные коды продукта нашей библиотеки, конфигурация которой описана в файлеfoo.qbs:
StaticLibrary { // Задаем тип библиотеки как статическую.
name: "foo" // Задаем уникальное имя библиотеки (будет на выходе foo.a).
Depends { name: "cpp" } // Задаем зависимость от QBS-ного модуля CPP.
Depends { name: "Qt"; submodules: "core" } // Говорим линковать с модулем QtCore.
files: [ "foo.cpp", "foo.h" ] // Перечисляем исходники библиотеки.
// Это специальный финт для экспорта директории с заголовками библиотеки, так,
// чтобы ее можно было подключать как '#include <foo/foo.h>' вместо
// '#include <foo.h>'.
property string libIncludeBase: ".."
cpp.includePaths: [libIncludeBase]
// Экспорт свойств продукта библиотеки для всех других продуктов, которые будут
// зависеть от этой библиотеки (экспортирует директорию с заголовками).
Export {
Depends { name: "cpp" }
cpp.includePaths: [product.libIncludeBase]
}
}Библиотека foo пусть будет статической и пусть содержит всего лишь один класс Foo с одним методом encode():
#pragma once
#include <QByteArray>
class Foo
{
public:
enum class Number { One, Two, Three };
QByteArray encode(Number number) const;
};Этот метод принимает на вход какое-то значение из перечисления и преобразует его в некоторое имя:
#include "foo.h"
QByteArray Foo::encode(Number number) const
{
switch (number) {
case Number::One:
return "one";
case Number::Two:
return "two";
case Number::Three:
return "three";
default:
return "unknown";
}
}
ШАГ2. Создаем автотест
Чтобы проверить что целевой метод:
QByteArray Foo::encode(Number number) constработает правильно, необходимо ему на вход подавать каждое значение из перечисления Number и сравнивать результат, возвращаемый методом, с ожидаемой строкой.
Для простоты эксперимента возьмем тестовый фреймворк QtTest из состава Qt, для чего немного расширим структуру проекта, добавив директорию tests:
COVERAGE-EXAMPLE
│ .gitignore
│ coverage-example.qbs
│
├───src
│ │ src.qbs
│ │
│ └───libs
│ │ libs.qbs
│ │
│ └───foo
│ foo.cpp
│ foo.h
│ foo.qbs
│
└───tests
│ tests.qbs
│
└───auto
│ auto.qbs
│
└───foo
foo.qbs
tst_foo.cppПри этом, файл coverage-example.qbs пополнится до такого содержимого:
Project {
name: "coverage-example"
references: [
"src/src.qbs",
"tests/tests.qbs" // Подключаем директорию с тестами в проект.
]
}, где:
tests/tests.qbs- директория содержащая исходные коды под-проектов тестов, которые перечислены в файлеtests.qbs(в нашем случае это будут только под-проекты автотестов):
Project {
name: "tests" // Задаем уникальное имя для под-проекта тестов.
references: [
"auto/auto.qbs" // Подключаем директорию с автотестами в проект.
]
}auto/- директория содержащая только под-проекты автотестов, которые перечислены в файлеauto.qbs(на данный момент содержит только один автотестfooдля нашей библиотекиfoo):
Project {
name: "autotests" // Задаем уникальное имя для под-проекта с автотестами.
references: [
"foo/foo.qbs" // Подключаем директорию с исходниками автотеста 'foo' в проект.
]
} auto/foo/- директория содержащая продукт приложения автотеста для библиотекиfoo, конфигурация которого описана в файлеfoo.qbs:
CppApplication { // Задаем тип автотеста как С++ приложение.
name: "tst_foo" // Задаем уникальное имя приложения автотеста.
Depends { name: "Qt"; submodules: ["test"] } // Говорим линковать с модулем QtTest.
Depends { name: "foo" } // Говорим линковать с нашей библиотекой 'foo'.
files: ["tst_foo.cpp"] // Перечисляем исходники автотеста.
}Приложение автотеста tst_foo.cpp содержит следующий код:
#include <foo/foo.h>
#include <QtTest>
Q_DECLARE_METATYPE(Foo::Number)
class tst_Foo final : public QObject
{
Q_OBJECT
private slots:
void encode_data();
void encode();
};
void tst_Foo::encode_data()
{
QTest::addColumn<Foo::Number>("number");
QTest::addColumn<QByteArray>("name");
QTest::newRow("one") << Foo::Number::One << QByteArray("one");
QTest::newRow("two") << Foo::Number::Two << QByteArray("two");
QTest::newRow("three") << Foo::Number::Three << QByteArray("three");
QTest::newRow("unknown") << static_cast<Foo::Number>(123) << QByteArray("unknown");
}
void tst_Foo::encode()
{
QFETCH(Foo::Number, number);
QFETCH(QByteArray, name);
Foo foo;
const auto encoded = foo.encode(number);
QCOMPARE(encoded, name);
}
QTEST_MAIN(tst_Foo)
#include "tst_foo.moc" Здесь:
метод теста
tst_Foo:encode_data()формирует набор датасетов, подаваемых в проверяемый методFoo::encode()библиотеки.метод теста
tst_Foo::encode()запускает по очереди целевую функцию из библиотеки с каджым из датасетов.
Примечание: Это все магия QtTest, с которой подробнее можно ознакомиться из оффициальной документации Qt.
ШАГ3. Запускаем автотест еще без покрытия кода
Для проверки того, что наш автотест работает как надо, нам просто необходимо его запустить (автотест - это просто обычное приложение). В процессе работы он выдаст результат, похожий на этот:
********* Start testing of tst_Foo *********
Config: Using QtTest library 5.14.2, Qt 5.14.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 10.2.0)
PASS : tst_Foo::initTestCase()
PASS : tst_Foo::encode(one)
PASS : tst_Foo::encode(two)
PASS : tst_Foo::encode(three)
PASS : tst_Foo::encode(unknown)
PASS : tst_Foo::cleanupTestCase()
Totals: 6 passed, 0 failed, 0 skipped, 0 blacklisted, 0ms
********* Finished testing of tst_Foo *********ШАГ4. Добавляем опцию --coverage
Чтобы информация о покрытии генерировалась в процессе работы автотеста, необходимо добавить опцию --coverage и компилятору и линковщику, а также собирать проект с отключенной оптимизацией (например, это дебаг режим).
В нашем случае при сборке статической библиотеки до линковки дело не доходит, т.к. здесь работает только компилятор и архиватор. А вот уже приложение автотеста и компилируется и линкуется. Поэтому опцию --coverage нужно добавить в два разных продукта в разные шаги сборки:
и в библиотеку (только компилятору)
и в автотест (и компилятору и линковщику).
Для этого QBS предоставляет модуль cpp, который имеет сециально предназначенные для этого свойства. В нашем случае, свойство cpp.driverFlags - то что нужно, оно передаст опцию --coverage и компилятору и линковщику.
Простой и самый напрашивающийся вариант - это продублировать свойство cpp.driverFlags и в продукт библиоеки и в продукт автотеста. Но это решение некрасивое, и есть более изящный подход, используя мощь QBS. ;)
Мы просто создадим дополнительный QBS модуль, и назовем его для примера как coverage. Этот модуль будет подставлять нужные опции сам автоматически. Достаточно только его подключить как зависимость к продукту. Для этого придется немного расширить дерево проекта:
COVERAGE-EXAMPLE
│ .gitignore
│ coverage-example.qbs
│
├───qbs
│ └───modules
│ └───coverage
│ coverage.qbs
│
├───src
│ │ src.qbs
│ │
│ └───libs
│ │ libs.qbs
│ │
│ └───foo
│ foo.cpp
│ foo.h
│ foo.qbs
│
└───tests
│ tests.qbs
│
└───auto
│ auto.qbs
│
└───foo
foo.qbs
tst_foo.cpp, где:
qbs/- директория в которой находятся наши вспомогательные QBS модули или файлы импорта.qbs/modules/- директория содержащая вспомогательные модули (должна иметь имяmodules).qbs/modules/coverage/- директория, содержащая исходный QBS код нашего вспомогательного модуляcoverageописанного в файлеcoverage.qbs:
Module {
// Задаем условие что этот модуль активен только для компилятора GCC
// и только если текущая конфигурация есть debug.
condition: qbs.debugInformation && qbs.toolchain.contains("gcc")
Depends { name: "cpp" } // Добавляем зависимость от QBS-ного модуля CPP.
cpp.driverFlags: ["--coverage"] // Задаем флаги и компилятору и линковщику.
}Далее, добавляем этот модуль как зависимость к продукту библиотеки в файле foo.qbs:
StaticLibrary {
name: "foo"
Depends { name: "cpp" }
Depends { name: "coverage" } // Добавляем зависимость от модуля coverage.
Depends { name: "Qt"; submodules: "core" }
files: [ "foo.cpp", "foo.h" ]
property string libIncludeBase: ".."
cpp.includePaths: [libIncludeBase]
Export {
Depends { name: "cpp" }
Depends { name: "coverage" } // Экспортируем зависимость от модуля coverage.
cpp.includePaths: [product.libIncludeBase]
}
}Теперь при сборке библиотеки, будет добавлена опция --coverage компилятору. А благодаря тому, что мы экспортировали зависимость от модуля coverage из библиотеки foo с помощью Export , то теперь любой продукт, подключивший библиотеку foo также получит эту опцию --coverage. Таким образом, мы убиваем сразу двух (и более зайцев).
И почти последгий штрих - надо указать QBS где искать наш новый модуль coverage. Для этого нужно добавить в корневой файл проекта coverage-example.qbs одну строчку:
Project {
name: "coverage-example"
qbsSearchPaths: "qbs" // Говорим QBS что искать наши модули в директории qbs
references: [
"src/src.qbs",
"tests/tests.qbs"
]
} На этом, казалось бы, этот шаг должен был быть завершен - но нет. После включения опции --coverage после сборки библиотеки и приложения автотеста, в директории с объектными файлами автоматически будут создаваться файлы с расширением *.gcno:
user@ubuntu:~/Documents/coverage-git/build-coverage-example-Desktop-Debug/Debug_Desktop_038b678e9426a45b$ ls foo.0beec7b5/3a52ce780950d4d9/
foo.cpp.gcno foo.cpp.o
user@ubuntu:~/Documents/coverage-git/build-coverage-example-Desktop-Debug/Debug_Desktop_038b678e9426a45b$ ls tst-foo.e3f741e4/3a52ce780950d4d9/
tst_foo.cpp.gcda tst_foo.cpp.gcno tst_foo.cpp.oНо мы не хотим держать эту помойку и пускать все на самотек. Мы хотим, чтобы при операции clean очищалась вся директория сборки. Для этого нужно добавить в модуль coverage правило, которое обрабатывало бы файлы *.gcno как артефакты (т.е. включить их в граф сборки QBS).
import qbs.FileInfo // Импортирует QBS-ный сервис для работы с инфой о файлах.
import qbs.Utilities // Импортируем QBS-ные вспомогательные функции из утилит.
Module {
condition: qbs.debugInformation && qbs.toolchain.contains("gcc")
additionalProductTypes: ["gcno"] // Говорим что обязательно использовать тег gcno.
Depends { name: "cpp" }
cpp.driverFlags: ["--coverage"]
Rule { // Правило для фейковой генерации файлов *.gcno.
// Говорим что как будто мы будем генерировать файлы *.gcno из
// сорцов *.cpp или *.c.
inputs: ["cpp", "c"]
// Задаем имя тега для генерируемого артефакта (любое,
// пусть будет gcno).
outputFileTags: ["gcno"]
// Описываем свойства генерируемого артефакта:
// - то что файлам *.gcno присваивается тег gcno.
// - то что файлы *.gcno будут создаваться в определенном месте
// (рядом с объектниками).
outputArtifacts: {
return [{
fileTags: ["gcno"],
filePath: FileInfo.joinPaths(Utilities.getHash(input.baseDir),
input.fileName + ".gcno")
}];
}
// Описываем код правила, т.е. как мы будем из файлов *.c *.cpp
// делать файлы *.gcno. А никак - мы не контролируем этот процесс,
// т.к. сам компилятор этим занимается автоматически. Поэтому код
// этого правила - просто пуская команда, которая ничего не делает,
// кроме того что просто печатает в коноль сообщение:
// generating foo.gcno
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "generating " + output.fileName;
return [cmd];
}
}
}Примечание:
Т.к. выходной артифакт
gcnoникому не нужен (он не включен ни в какую зависимость) то чтобы правило заработало, необходимо явно сказать QBS-у чтобы он всегда запускал это правило с помощью опции модуляadditionalProductTypes.Т.к. наше правило ничего не делает (просто регистрирует файлы *.gcno как артефакты), то и его код должен ничего не делать тоже.
ШАГ5. Запускаем автотест уже с покрытием кода
Теперь запускаем снова наше приложение автотеста. И видим, что он отработал как обычно (вывел в консоль результаты):
********* Start testing of tst_Foo *********
Config: Using QtTest library 5.14.2, Qt 5.14.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 10.2.0)
PASS : tst_Foo::initTestCase()
PASS : tst_Foo::encode(one)
PASS : tst_Foo::encode(two)
PASS : tst_Foo::encode(three)
PASS : tst_Foo::encode(unknown)
PASS : tst_Foo::cleanupTestCase()
Totals: 6 passed, 0 failed, 0 skipped, 0 blacklisted, 0ms
********* Finished testing of tst_Foo *********Но теперь рядом с объектными файлами библиотеки и приложения автотеста автоматически сгенерировались бинарные файлы отчетов *.gcda:
user@ubuntu:~/Documents/coverage-git/build-coverage-example-Desktop-Debug/Debug_Desktop_038b678e9426a45b$ ls foo.0beec7b5/3a52ce780950d4d9/
foo.cpp.gcda foo.cpp.gcno foo.cpp.o
user@ubuntu:~/Documents/coverage-git/build-coverage-example-Desktop-Debug/Debug_Desktop_038b678e9426a45b$ ls tst-foo.e3f741e4/3a52ce780950d4d9/
tst_foo.cpp.gcda tst_foo.cpp.gcno tst_foo.cpp.oНо мы лентяи не не хотим вручную запускать автотесты. Для этого у QBS уже имеется специальный объект AutotestRunner, который достаточно добавить в корневой проект coverage-example.qbs :
Project {
name: "coverage-example"
qbsSearchPaths: "qbs"
AutotestRunner { }
references: [
"src/src.qbs",
"tests/tests.qbs"
]
}И всем продуктам приложениям автотестов просто добавить тег autotest (в нашем случае у нас один объект автотеста в tests/auto/foo/foo.qbs):
CppApplication {
name: "tst_foo"
type: base.concat("autotest") // Добавили новый тег - автотест.
Depends { name: "Qt"; submodules: ["test"] }
Depends { name: "foo" }
files: ["tst_foo.cpp"]
}И тепрерь, при сборке нашего раннера, QBS автоматически отследит все его зависимости (они являются автотестами), соберет их (если еще не собраны), и запустит по очереди.
ШАГ6. Генерируем красивые результаты
Итак, чтобы сгенерировать красивые результаты покрытия в виде HTML страниц, необходимо обработать все бинарные файлы результатов утилитой lcov.
Чтобы автоматизировать этот процесс - напишем свой зарускатель автотестов, т.к. стандартный AutotestRunner не годится для этой цели. Причина в том, что нам нужно не только запускать автотест, но и написать правила, которые будут отслеживать генерируемые файлы *.gcda как выходные артефакты и подавать их на вход утилите lcov.
Назовем наш новый запускатель как CoverageRunner и поместим его реализацию в директорию imports:
COVERAGE-EXAMPLE
│ .gitignore
│ coverage-example.qbs
│
├───qbs
│ ├───imports
│ │ CoverageRunner.qbs
│ │
│ └───modules
│ └───coverage
│ coverage.qbs
│
├───src
│ │ src.qbs
│ │
│ └───libs
│ │ libs.qbs
│ │
│ └───foo
│ foo.cpp
│ foo.h
│ foo.qbs
│
└───tests
│ tests.qbs
│
└───auto
│ auto.qbs
│
└───foo
foo.qbs
tst_foo.cpp, где:
qbs/imports/- диретория, содержащая разные реализации вспомогательных объектов.
В нашем случае она содержит только одну реализацию объекта нашего запускателя в файле CoverageRunner.qbs :
import qbs.File
import qbs.FileInfo
import qbs.ModUtils
import qbs.Probes
import qbs.Utilities
Product {
name: "coverage-runner" // Задаем уникальное имя нашему запускателю тестов.
// Задаем тег конечного выходного артефакта в цепочке всех промежуточных
// артефактов, генерируемым нашим запускателем. Конечный артефакт - это
// информация о покрытии в виде HTML страниц.
type: ["out_html"]
// Говорим QBS-у чтобы он собирал этот запускатель только при явном указании.
builtByDefault: false
// Задаем переменные окружения для запуска тестов и утилиты lcov.
property stringList environment: ModUtils.flattenDictionary(qbs.commonRunEnvironment)
// Задаем путь к утилите lcov, найденный пробником.
property path lcovPath: lcovProbe.filePath
// Задаем путь к утилите genhtml, найденный пробником.
property path genhtmlPath: genhtmlProbe.filePath
// Пробник, который ишет утилиту lcov.
Probes.BinaryProbe {
id: lcovProbe
names: "lcov"
}
// Пробник, который ищет утилиту genhtml.
Probes.BinaryProbe {
id: genhtmlProbe
names: "genhtml"
}
// Задаем зависимости в виде любых продуктов с тегом autotest.
Depends {
productTypes: "autotest"
limitToSubProject: true
}
// Реализуем первое правило в цепочке, которое будет запускать автотесты
// и добавляет генерируемые ими выходные файлы *.gcna в граф сборки.
Rule {
id: gcnoGenerator
inputsFromDependencies: ["application"]
// Задаем выходной тег артефактам, и полный путь к файлам генерируемым
// этим правилом.
outputFileTags: ["gcda"]
outputArtifacts: {
var artifacts = [];
function traverse(dep) {
var gcnos = dep.artifacts["gcno"] || [];
gcnos.forEach(function(gcno) {
artifacts.push({
fileTags: ["gcda"],
filePath: FileInfo.joinPaths(FileInfo.path(gcno.filePath), gcno.completeBaseName + ".gcda")
});
});
dep.dependencies.forEach(traverse);
}
product.dependencies.forEach(traverse);
return artifacts;
}
prepare: {
if (!input.product.type.contains("autotest")) {
var cmd = new JavaScriptCommand();
cmd.silent = true;
return cmd;
}
var commandFilePath;
var installed = input.moduleProperty("qbs", "install");
if (installed)
commandFilePath = ModUtils.artifactInstalledFilePath(input);
if (!commandFilePath || !File.exists(commandFilePath))
commandFilePath = input.filePath;
var arguments = (input.autotest && input.autotest.arguments && input.autotest.arguments.length > 0) ? input.autotest.arguments : [];
var workingDir = (input.autotest && input.autotest.workingDir) ? input.autotest.workingDir : FileInfo.path(commandFilePath);
var fullCommandLine = [].concat([commandFilePath]).concat(arguments);
var cmd = new Command(fullCommandLine[0], fullCommandLine.slice(1));
cmd.description = "running test " + input.fileName;
cmd.environment = product.environment;
cmd.workingDirectory = workingDir;
cmd.jobPool = "coverage-runner";
if (input.autotest && input.autotest.allowFailure)
cmd.maxExitCode = 32767;
return cmd;
}
}
// Реализуем второе правило в цепочке. Оно берет на вход все сгенерированные
// файлы *.gcda, подает их утилите lcov для генерации результатов покрытия
// в текстовой форме в виде файлов с расширением *.info.
Rule {
id: infoGenerator
inputs: ["gcda"] // Задаем брать все бинарные файлы *.gcda на вход правилу.
// Задаем выходной тег для артефактов, и полный путь файлов, генерируемых
// этим правилом.
outputFileTags: ["src_info"]
outputArtifacts: {
return [{
fileTags: ["src_info"],
filePath: FileInfo.joinPaths(Utilities.getHash(input.baseDir), input.fileName + ".info")
}];
}
// Этот код запускает утилиту lcov для каждого из входных файлов *.gcda и
// формирует выходные файлы с текстовой информацией *.info.
prepare: {
var args = ["--quiet", "--capture"];
args.push("--directory", FileInfo.path(input.filePath));
args.push("--output-file", output.filePath);
var cmd = new Command(product.lcovPath, args);
cmd.description = "generating " + output.fileName;
return cmd;
}
}
// Реализуем третье правило в цепочке. Оно берет на вход все файлы *.info и
// объединяет их в один общий файл с именем <имя продукта>.info, который помещает
// рядом с исполняемым файлом автотестов (я так захотел).
Rule {
id: infoMerger
multiplex: true
inputs: ["src_info"] // Задаем брать все текстовые файлы *.info.
// Задаем выходной тег артифакта, и полный путь к объединенному *.info
// файлу генерируемому этим правилом.
outputFileTags: ["out_info"]
outputArtifacts: {
return [{
fileTags: ["out_info"],
filePath: FileInfo.joinPaths(product.destinationDirectory, product.targetName + ".info")
}];
}
// Этот код запускает утилиту lcov для объелинения всех входных файлов
// *.info в один результирующий файл *.info.
prepare: {
var args = ["--quiet"];
inputs.src_info.forEach(function(info) {
args.push("--add-tracefile", info.filePath);
});
args.push("--output-file", output.filePath);
var cmd = new Command(product.lcovPath, args);
cmd.description = "generating " + output.fileName;
return cmd;
}
}
// Реализуем четвертое (и последнее) правилло в цепочке. Оно берет на вход
// результирующий текстовый файл *.info и подает его утилите genhtml для
// генерации результата в виде HTML страниц.
Rule {
id: htmlGenerator
inputs: ["out_info"] // Задаем брать результирующий текстовый файл.
// Задаем выходной тег артифакта и полный путь к директории с HTML
// страницами, генерируемыми этим правилом.
// Имя этого тега должно совпадать с именем пега продукта - запускателя.
outputFileTags: ["out_html"]
outputArtifacts: {
return [{
fileTags: ["out_html"],
filePath: FileInfo.joinPaths(product.destinationDirectory, "html")
}];
}
// Этот код запускает утилиту genhtml для генерации HTML станиц из
// результирующего файла *.info.
prepare: {
var args = ["--quiet", "--ignore-errors"];
args.push("source", input.filePath);
args.push("--output-directory", output.filePath);
var cmd = new Command(product.genhtmlPath, args);
cmd.description = "generating html";
return cmd;
}
}
}Этот запускатель реализует набор правил, выстроенных в цепочку в графе сборки. При сборке запускателя будут выполненны следующие действия:
Запуск автотестов для генерации бинарных файлов
*.gcda.Подача всех файлов
*.gcdaв утилиту lcov для генерации текстовых фалов*.info.Подача всех текстовых файлов
*.infoв утилиту lcov для их объединения в один результирующий файл*.info.Подача результирующего текстового файла
*.infoв утилиту genhtml для генерации HTML страниц о покрытии кода.
Далее, необходимо модифицировать корневой файл проекта coverage-example.qbs, заменив в нем AutotestRunner на наш CoverageRunner :
import "qbs/imports/CoverageRunner.qbs" as CoverageRunner // Импортируем наш запускатель
Project {
name: "coverage-example"
qbsSearchPaths: "qbs"
CoverageRunner { } // Декларируем наш запускатель.
references: [
"src/src.qbs",
"tests/tests.qbs"
]
}Теперь, для генерации результатов покрытия в виде HTML страниц достаточно просто выполнить сборку нашего продукта - запускателя тестов coverage-runner.
ШАГ7. Просматриваем результаты покрытия
После сборки нашего запускателя, он сгенерирует результаты покрытия в виде HTML страниц в выходную директорию сборки запускателя, например:
user@ubuntu:~/Documents/coverage-git/build-coverage-example-Desktop-Debug/Debug_Desktop_038b678e9426a45b$ ls coverage-runner.90e4c3ec/html/
amber.png emerald.png gcov.css glass.png home index.html index-sort-f.html index-sort-l.html QtCore QtTest ruby.png snow.png updown.png usrТеперь мы можем открыть файл index.html и посмотреть что получилось:
Конечно, здесь добавляется и лишняя информация. Но это не проблема, т.к. ее можно исключить на этапе генерации файлов *.info, но мы не будем касаться этого в данной статье.
Результаты покрытия по нашей библиотеки примерно следующие:
Теперь можете сами поиграться с содержимым автотеста, например, закомментировав некоторые строчки дата-сетов, перегенерировать HTML и посмотреть что поменяется. ;)
Заключение
В этой статье краттко рассмотрели всю мощь и гибкость QBS для реализации самых разнообразных задач.
И, конечно, ссылки:
