Test unit filtering . Boost , Boost.Test , Runtime parameters

Test unit filtering

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

Default run status

Каждая тестовая единица (либо тестовый корпус, либо тестовый набор) имеет соответствующийстатус запуска по умолчанию.. Он может принимать одно из трех значений:

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

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

Вы можете установить другой статус запуска по умолчанию в любом тестовом блоке, используядекораторы:<disabled>,<enabled>и<enable_if>. Статус запуска по умолчанию устанавливается один раз при инициализации программы тестирования и не может быть изменен. Отключенные тесты не выполняются по умолчанию, но все еще присутствуют в тестовом дереве и перечислены вместе с другими тестами, когда вы используете аргумент командной строки<list_content>.

Example: default run status

Код

#defineBOOST_TEST_MODULEdecorator_20
#include<boost/test/included/unit_test.hpp>
namespaceutf=boost::unit_test;
constboolio_implemented=true;
constbooldb_implemented=false;
BOOST_AUTO_TEST_SUITE(suite1,*utf::disabled())
 BOOST_AUTO_TEST_CASE(test_1)
 {
   BOOST_TEST(1!=1);
 }
 BOOST_AUTO_TEST_CASE(test_2,*utf::enabled())
 {
   BOOST_TEST(2!=2);
 }
 BOOST_AUTO_TEST_CASE(test_io,
   *utf::enable_if<io_implemented>())
 {
   BOOST_TEST(3!=3);
 }
 BOOST_AUTO_TEST_CASE(test_db,
   *utf::enable_if<db_implemented>())
 {
   BOOST_TEST(4!=4);
 }
BOOST_AUTO_TEST_SUITE_END()

выход

>decorator_20
Running2testcases...
test.cpp(18):error:in"suite1/test_2":check2!=2hasfailed[2==2]
test.cpp(24):error:in"suite1/test_io":check3!=3hasfailed[3==3]
***2failuresaredetectedinthetestmodule"decorator_20"
>decorator_20--list_content
suite1*
   test_1
   test_2*
   test_io*
   test_db

Dynamic test dependencies

Кроме того, можно статически связать испытательный блок с условием. Это связанное состояние оценивается непосредственно перед выполнением тест-блока. Если условие выполнено, тестовый блок выполняется. В противном случае испытательный блокпропущен. Можно добавить две зависимости:

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

Command-line control

Статическая конфигурация фильтрации тестового корпуса используется по умолчанию, если не применяется фильтрация командной строки. С помощью аргумента командной строки<run_test>можно изменить статическую предустановку несколькими способами:

Игнорируйте статическую конфигурацию и вручную укажите тестовые случаи для запуска.
Увеличьте статически определенный набор, включив тестовые случаи для инвалидов.
Сократите статически определенный набор, отключив некоторые включенные тестовые случаи.

Absolute specification

Термин «абсолютный» в этом контексте означает, что статус запуска тестовых блоков по умолчанию, который был статически настроен, полностью игнорируется, а тесты, которые должны быть запущены, указаны вручную с нуля. Во-первых, чтобы узнать, какие тестовые блоки зарегистрированы в тестовом дереве, пользователю необходимо использовать аргумент командной строки<list_content>. Далее, чтобы указать набор тестовых случаев, пользователю необходимо использовать аргумент командной строки<run_test>с абсолютным значением:

> test_program --run_test=<test_set>

Формат<<test_set>>значения может принимать ряд форм. Учитывая следующую программу:

#define BOOST_TEST_MODULE example
#include <boost/test/included/unit_test.hpp>
using boost::unit_test::label;
BOOST_AUTO_TEST_CASE(test_1, *label("L1")) {}
BOOST_AUTO_TEST_CASE(test_2, *label("L1")) {}
BOOST_AUTO_TEST_SUITE(suite_1)
  BOOST_AUTO_TEST_SUITE(suite_1)
    BOOST_AUTO_TEST_CASE(test_1) {}
    BOOST_AUTO_TEST_CASE(test_2) {}
  BOOST_AUTO_TEST_SUITE_END()
  BOOST_AUTO_TEST_SUITE(suite_2)
    BOOST_AUTO_TEST_CASE(test_1, *label("L2")) {}
    BOOST_AUTO_TEST_CASE(test_2, *label("L2")) {}
  BOOST_AUTO_TEST_SUITE_END()
  BOOST_AUTO_TEST_CASE(test_1, *label("L1")) {}
  BOOST_AUTO_TEST_CASE(test_2) {}
  BOOST_AUTO_TEST_CASE(test_2A) {}
BOOST_AUTO_TEST_SUITE_END()

Следующая таблица иллюстрирует, как различные значения<<test_set>>контролируют, какие тестовые случаи выполняются.

Описание	Значение параметра	Тестовые случаи
Запуск одного теста верхнего уровня по имени	< `run_test`=test_1 >	< test_1 >
Запуск одного вложенного тест-кейса по имени	< `run_test`=suite_1/suite_1/test_1 >	< suite_1/suite_1/test_1 >
Запуск одноместного тестового набора по имени	< `run_test`=suite_1/suite_2 `run_test`=suite_1/suite_2/* >	< suite_1/suite_2/test_1 suite_1/suite_2/test_2 >
Запуск нескольких испытательных блоков, которые являютсябратьями и сестрамитого же набора тестов	< `run_test`=suite_1/test_1,suite_2 >	< suite_1/suite_2/test_1 suite_1/suite_2/test_2 suite_1/test_1 >
Запуск нескольких тестовых блоков, которые не обязательно являются братьями и сестрами	< `run_test`=suite_1/test_1:test_1 >	< suite_1/test_1 test_1 >
Проведите все тесты, соответствующие заданной этикетке	< `run_test`=@L1 >	< test_1 test_2 suite_1/test_1 >
Проведите каждый тест на дереве	< `run_test`=* >	< test_1 test_2 suite_1/suite_1/test_1 suite_1/suite_1/test_2 suite_1/suite_2/test_1 suite_1/suite_2/test_2 suite_1/test_1 suite_1/test_2 suite_1/test_2A >
Запуск каждого тестового блока в заданном наборе с заданным префиксом	< `run_test`=suite_1/test* >	< suite_1/test_1 suite_1/test_2 suite_1/test_2A >
Запуск каждого тестового блока в заданном наборе с заданным суффиксом	< `run_test`=suite_1/*_1 >	< suite_1/suite_1/test_1 suite_1/suite_1/test_2 suite_1/test_1 >
Запуск каждого тестового блока в заданном наборе с заданным исправлением	< `run_test`=suite_1/_2 >	< suite_1/suite_2/test_1 suite_1/suite_2/test_2 suite_1/test_2 suite_1/test_2A >
Тест(ы) выполнения с заданным именем в любом наборе N-уровня	< `run_test`=//test_2 >	< suite_1/suite_1/test_2 suite_1/suite_2/test_2 >

Для синтаксических производств, описывающих структуру<<test_set>>значения см.здесь.

В то время как использование спецификации абсолютного тестового случая игнорирует статус запуска по умолчанию, она не игнорирует зависимости динамического тестирования. Если испытательный блок<B>зависит от испытательного блока<A>и тест<B>задается для запуска<run_test>,<A>также запускается, даже если он не указан, и его отказ может привести к пропуску выполнения<B>. Аналогичным образом, неудавшаяся проверка<precondition>может привести к пропуску выбранного испытания.

Example: run_test and dynamic dependencies

Код

#defineBOOST_TEST_MODULEdecorator_21
#include<boost/test/included/unit_test.hpp>
namespaceutf=boost::unit_test;
namespacett=boost::test_tools;
tt::assertion_resultfail(utf::test_unit_id)
{
 tt::assertion_resultans(false);
 ans.message()<<"precondition failed";
 returnans;
}
BOOST_AUTO_TEST_CASE(test_1)
{
 BOOST_TEST(false);
}
BOOST_AUTO_TEST_CASE(test_2,
 *utf::depends_on("test_1"))
{
 BOOST_TEST(true);
}
BOOST_AUTO_TEST_CASE(test_3,
 *utf::precondition(fail))
{
 BOOST_TEST(true);
}

выход

>decorator_21--log_level=test_suite--run_test=test_2,test_3
Includingtestcasetest_1asadependencyoftestcasetest_2
Running3testcases...
Enteringtestmodule"decorator_21"
test.cpp(14):Enteringtestcase"test_1"
test.cpp(16):error:in"test_1":checkfalsehasfailed
test.cpp(14):Leavingtestcase"test_1";testingtime:3ms
test.cpp(26):Testcase"test_3"isskippedbecausepreconditionfailed
test.cpp(20):Testcase"test_2"isskippedbecausedependencytestcase"test_1"hasfailed
Leavingtestmodule"decorator_21";testingtime:17ms
***1failureisdetectedinthetestmodule"decorator_21"

Relative specification

Термин «относительный» в этом контексте означает, что конфигурация основана либо на состоянии выполнения тестовых блоков по умолчанию, либо на переопределении командной строки, указанном вабсолютной спецификации; и, кроме того, мы дополнительно либо включаем некоторые отключенные тестовые блоки, либо отключаем некоторые включенные тестовые блоки. Относительная спецификация управляется аргументом командной строки<run_test>, причем значение используется с использованием аналогичного синтаксиса, как и в абсолютной спецификации, но предшествует либо символу<'!'>для отключения включенных тестовых блоков, либо символу<'+'>для включения отключенных тестовых блоков. Это можно резюмировать в следующей таблице:

командовать	Тип спецификации	семантика
< > test_program --`run_test`=!<absolute_spec> >	отключатель	Включены тестовые блоки, соответствующие<`<absolute_spec>`>.
< > test_program --`run_test`=+<absolute_spec> >	Включатель	Включены тестовые блоки с инвалидностью, которые соответствуют<`<absolute_spec>`>, а также их зависимости от потока.

Спецификацияиспользуется для включения набора тестовых блоков, которые изначально отключены.

Example: command-line enabler

Код

#defineBOOST_TEST_MODULEdecorator_22
#include<boost/test/included/unit_test.hpp>
namespaceutf=boost::unit_test;
BOOST_AUTO_TEST_CASE(test_1)
{
 BOOST_TEST(true);
}
BOOST_AUTO_TEST_CASE(test_net,
 *utf::disabled()
 *utf::description("requires network"))
{
 BOOST_TEST(true);
}

выход

>decorator_22--list_content
test_1*
test_net:requiresnetwork
>decorator_22--log_level=test_suite
Running1testcase...
Enteringtestmodule"decorator_22"
test.cpp(6):Enteringtestcase"test_1"
test.cpp(6):Leavingtestcase"test_1"
Leavingtestmodule"decorator_22";testingtime:5ms
***Noerrorsdetected
>decorator_22--log_level=test_suite--run_test=+test_net
Running2testcases...
Enteringtestmodule"decorator_22"
test.cpp(6):Enteringtestcase"test_1"
test.cpp(6):Leavingtestcase"test_1";testingtime:1ms
test.cpp(13):Enteringtestcase"test_net"
test.cpp(13):Leavingtestcase"test_net";testingtime:1ms
Leavingtestmodule"decorator_22";testingtime:16ms
***Noerrorsdetected

И наоборот, спецификацияотключателяиспользуется для отключения набора тестовых блоков, которые первоначально включены.

Example: command-line disabler

Код

#defineBOOST_TEST_MODULEdecorator_23
#include<boost/test/included/unit_test.hpp>
namespaceutf=boost::unit_test;
BOOST_AUTO_TEST_CASE(test_1)
{
 BOOST_TEST(true);
}
BOOST_AUTO_TEST_CASE(test_net,
 *utf::description("requires network"))
{
 BOOST_TEST(true);
}

выход

>decorator_23--list_content
test_1*
test_net*:requiresnetwork
>decorator_23--log_level=test_suite
Running2testcases...
Enteringtestmodule"decorator_23"
test.cpp(6):Enteringtestcase"test_1"
test.cpp(6):Leavingtestcase"test_1"
test.cpp(12):Enteringtestcase"test_net"
test.cpp(12):Leavingtestcase"test_net"
Leavingtestmodule"decorator_23";testingtime:14ms
***Noerrorsdetected
>decorator_23--log_level=test_suite--run_test=!test_net
Running1testcase...
Enteringtestmodule"decorator_23"
test.cpp(6):Enteringtestcase"test_1"
test.cpp(6):Leavingtestcase"test_1"
Leavingtestmodule"decorator_23";testingtime:5ms

Если в одной командной строке есть как активатор, так и отключатель, которые определяют один и тот же тест, тест становится отключенным. То есть отключатель имеет приоритет над активатором.

Note

В то время как активатор дополнительно включает зависимости вверх по течению (введенные с декоратором<depends_on>), отключатель не отключает их. Поэтому, когда вы включаете и затем отключаете тот же тест, вы не отключаете его зависимости.

Статья Test unit filtering раздела Boost.Test Runtime parameters может быть полезна для разработчиков на c++ и boost.