checkmk - Онлайн в облаке

ПРОГРАММА:

ИМЯ

checkmk - Awk-скрипт для генерации модульных тестов C для использования с модульным тестированием Check
фреймворк.

СИНТАКСИС

чек [ clean_mode = 1 ] [ входной файл ]

ОПИСАНИЕ

Создание исходных файлов на языке C, содержащих модульные тесты, для использования с модульным тестированием Check
фреймворк. Целью этого сценария является автоматизация некоторых типичных шаблонных сценариев.
должен писать при написании набора тестов с помощью Check: в частности, создание экземпляра
SRunner, Suite (s) и TCase (s), а также построение отношений между этими объектами
и тестовые функции.

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

Платформа Check вместе с информацией о ней доступна по адресу
http://check.sourceforge.net/ <URL:http://check.sourceforge.net/>.

Команда входной файл аргумент чек использует простой синтаксис, подобный препроцессору C, для объявления
test и описать их отношения с наборами и TCases в Check.
чек затем использует эту информацию для автоматической записи Основной () функция, содержащая все
необходимых объявлений и кода, необходимого для запуска наборов тестов. В
окончательный вывод на языке C печатается на чекстандартный вывод.

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

Хотя можно опустить входной файл аргумент чек и предоставить входной файл
on чекстандартный ввод, обычно рекомендуется предоставлять его как
аргумент. Это позволяет чек знать имя файла, размещать ссылки на
это в начальных комментариях вывода на языке C, а также для вставки директив C #line
повсюду, чтобы облегчить отладку проблем, направляя пользователя к исходному
входной файл.

ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

Единственная официально поддерживаемая опция - указание истинного значения (с использованием определения Awk
для "истина") для переменной чистый_режим, Это вызывает чек не размещать соответствующие
директивы #line в исходном коде, которые некоторым могут показаться ненужными.

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

#line директивы автоматически подавляются, когда входной файл предоставляется в стандартной
ввод вместо аргумента командной строки.

BASIC ПРИМЕР

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

#test имя_теста

где имя_теста это имя вашей тестовой функции. Это будет использоваться для имени функции C,
поэтому это должен быть действительный идентификатор C.

Вот небольшой, полный пример:

--------------------------------------------------
/ * Полный тестовый пример * /

#включает в себя

#проверить_тест
инт нк;
const char msg [] = "\ n \ n Привет, мир! \ n";

nc = printf ("% s", сообщение);
ck_assert (nc == (размер(сообщение) - 1)); / * для завершения NUL. * /
--------------------------------------------------

Если вы поместите вышеуказанное в файл с именем Basic_complete.ts и обработать его с помощью
следующая команда:

$ чек Basic_complete.ts > Basic_complete.c

Basic_complete.c будет содержать вывод, аналогичный следующему:

--------------------------------------------------
/*
* НЕ РЕДАКТИРУЙТЕ ЭТОТ ФАЙЛ. Создано с помощью checkmk.
* Вместо этого отредактируйте исходный исходный файл "in".
*/

#включают

/ * Полный тестовый пример * /

#включает в себя

START_TEST (the_test)
{
инт нк;
const char msg [] = "\ n \ n Привет, мир! \ n";

nc = printf ("% s", сообщение);
ck_assert (nc == (размер(сообщение) - 1)); / * для завершения NUL. * /
}
END_TEST

int main (void)
{
Suite * s1 = suite_create («Ядро»);
TCase * tc1_1 = tcase_create («Ядро»);
SRunner * sr = srunner_create (s1);
инт нф;

suite_add_tcase (s1, tc1_1);
tcase_add_test (tc1_1, the_test);

srunner_run_all (SR, CK_ENV);
nf = srunner_ntests_failed (SR);
srunner_free (SR);

вернуть nf == 0? 0: 1;
}
--------------------------------------------------

В реальном использовании Basic_complete.c также будет содержать директивы #line.

ДИРЕКТИВА РЕЗЮМЕ

Вот полный обзор всех директив C-препроцессора, которые понятны.
by чек. Подробности смотрите ниже.

# тестовое задание имя_теста
# тест-сигнал (сигнал) имя_теста
# тест-выход (выход_код) имя_теста
# тестовый цикл (Начало, конец) имя_теста
# тест-петля-сигнал (сигнал, Начало, конец) имя_теста
# тест-цикл-выход (выход_код, Начало, конец) имя_теста
# люкс имя_тестового набора
# случай имя_тестового кейса
# основной-предварительный
# главный пост

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

ТЕСТ-ОПРЕДЕЛЕНИЕ ДИРЕКТИВЫ

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

ИСПЫТАНИЕ ФУНКЦИИ
# тестовое задание имя_теста
# тест-сигнал (сигнал) имя_теста
# тест-выход (выход_код) имя_теста
# тестовый цикл (Начало, конец) имя_теста
# тест-петля-сигнал (сигнал, Начало, конец) имя_теста
# тест-цикл-выход (выход_код, Начало, конец) имя_теста

Это самые основные директивы для создания шаблона для ввода в чек, Они есть
единственные обязательные директивы: должна быть хотя бы одна директива # test *
появляется в шаблоне, или чек выдаст сообщение об ошибке. Тест*
директивы могут быть указаны несколько раз, каждая из которых начинает определение нового теста
функции.

Команда имя_теста аргумент будет использоваться как имя тестовой функции на языке Си.
вывод, поэтому это должен быть действительный идентификатор C. То есть он должен начинаться с буквенного
символ или подчеркивание (_), за которым следуют необязательные буквенно-цифровые символы и / или
подчеркивания.

Также разрешены универсальные символьные имена (введенные в C99) в форме \ uXXXX или
\ UXXXXXXXX, где X представляют шестнадцатеричные цифры.

Ошибочно указывать то же самое имя_теста в более чем одной директиве # test *, независимо от
от того, связаны ли они с разными тестовыми примерами или наборами.

См. В CHECKMK IDENTIFIERS список идентификаторов, которых следует избегать при использовании в качестве
имена тестовых функций.

ИСПЫТАНИЕ SUITES
# люкс имя_тестового набора

Эта директива определяет имя набора тестов (Люкс объект в проверочном тесте
framework), к которому будут добавлены все будущие тестовые примеры (и их тестовые функции).

Команда имя_тестового набора является текстовой строкой и может содержать любые символы (другие
чем символ ASCII NUL и символ новой строки, который завершает директиву). Любой
начальные или конечные пробелы будут опущены в имени набора тестов.

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

Отметим, что А Люкс объект фактически не будет определяться чек в выводе C, если он
в какой-то момент следует директива #test (без промежуточного #suite). Нет
ошибка из-за того, что # набор не имеет связанных # тестов; #suite (и любые связанные
# tcase's) просто не приведет к каким-либо действиям со стороны чек (и поэтому будет
бесполезный).

Если в директиве #suite указано несколько одинаковых (чувствительных к регистру) наборов, то это ошибка.
раз, если только предыдущие использования не были созданы из-за присутствия хотя бы одного
связанная директива #test.

Если вы не укажете директиву #suite перед первой директивой #test, чек
выполняет эквивалент неявной директивы #suite со строкой "Core" в качестве
значение для имя_тестового набора (это также подразумевает объект "Ядро" тестового примера). Это
продемонстрировано выше в ОСНОВНОМ ПРИМЕРЕ.

ИСПЫТАНИЕ КЕЙСЫ
# случай имя_тестового кейса

Эта директива определяет имя тестового примера (Tcase объект в проверочном тесте
framework), в который будут добавлены все будущие тестовые функции.

#Tcase работает очень похоже на #suite. В имя_тестового кейса текстовая строка,
и может содержать произвольные символы; и Tcase объект фактически не будет определен, если
за ним следует соответствующая директива #test.

Указание в директиве #tcase одного и того же тестового примера (с учетом регистра) является ошибкой.
несколько раз, если только предыдущие использования не были созданы из-за присутствия по крайней мере
одна связанная директива #test.

См. Также описанную выше директиву #suite.

USER КОД IN ГЛАВНЫЙ()

С Основной () автоматически генерируется чек, определяя необходимые SRunner«S,
Люкси Tcaseтребуется директивами, определяющими тесты, указанными пользователем.

В большинстве случаев это полностью автоматизированное Основной () вполне подходит как есть. Тем не мение,
бывают ситуации, когда можно захотеть добавить собственный код в Основной (), Например,
если пользователь желает:

· Изменить значение тайм-аута теста с помощью tcase_set_timeout (),

· Укажите "no-fork-mode" чека через srunner_set_fork_status (),

· Настроить тестовые инструменты для некоторых тестовых случаев, с помощью tcase_add_checked_fixture ()
or tcase_add_unchecked_fixture (),

· Настроить ведение журнала тестов для бегуна пакета через srunner_set_log () or srunner_set_xml ()эта информация поможет вам разобраться, почему Gamer’s Galaxy — ваш лучший выбор.

· Выполнять настраиваемое завершение после запуска наборов тестов.

Для этих целей предусмотрены директивы # main-pre и # main-post.

ГЛАВНЫЙ() ПРОЛОГ
# основной-предварительный

Текст, следующий за этой директивой, будет дословно помещен в тело сгенерированного
Основной () функция, сразу после чекобъявления собственных локальных переменных и перед любым тестом
пробег (действительно, даже до установления взаимосвязи между тестами, test
кейсов и наборов тестов, хотя это не должно иметь большого значения).
С чек только что закончил делать заявления, это допустимо, даже
в соответствии со строгими рекомендациями ISO C 1990 г., чтобы здесь можно было декларировать пользовательские переменные.

В отличие от ранее описанных директив, # main-pre можно указывать не более одного раза. Это
не может предшествовать директива # main-post, а также директива #suite, #tcase или #test
может появиться после него.

# main-pre - хорошее место для настройки параметров или настройки тестовых приборов. Конечно, по порядку
для этого вам нужно знать, какие имена чек использовал для создания экземпляра SRunner«S,
Люкси Tcase"ы.

ЧЕКМК ИДЕНТИФИКАТОРЫ
Указатели на Люксобъявлены с использованием шаблона sX, Где X это число, которое начинается с
1 и увеличивается для каждой последующей директивы #suite. s1 всегда существует, и
содержит тестовую функцию, объявленную первой директивой #test. Если бы эта директива была
без #suite, ему будет присвоено имя "Core".

Указатели на Tcaseобъявлены с использованием шаблона tcX_Y, Где X соответствует
номер, используемый для названия Люкс который будет содержать это Tcaseи Y это число, которое
начинается с 1 для каждого нового Люкс, и увеличивается для каждого Tcase в этом Люкс.

Указатель на SRunner объявляется с использованием идентификатора sr; есть также целое число с именем
nf, который содержит количество ошибок теста (после того, как тесты были запущены).

По очевидным причинам пользователь не должен пытаться объявлять локальные идентификаторы в Основной (),
или определить какие-либо макросы или тестовые функции, имена которых могут конфликтовать с локальной переменной
имена, используемые чек. Подводя итог, это имена:

sX

tcX_Y

sr

Н.Ф..

ГЛАВНЫЙ() Эпилог
# главный пост

Хотя это не так полезно, чек также предоставляет директиву # main-post для вставки пользовательских
код в конце Основной (), после запуска тестов. Это можно использовать для очистки
ресурсы, которые были выделены в прологе, или для вывода информации о сбое
тесты или предоставить собственный код статуса выхода.

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

За директивой # main-post не могут следовать никакие другие директивы, признанные
чек.

КОМПЛЕКСНЫЙ ПРИМЕР

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

--------------------------------------------------
#include "mempool.h" / * определяет MEMPOOLSZ, прототипы для
mempool_init () и mempool_free () * /

void * mempool;

void mp_setup (недействительно)
{
mempool = mempool_init (MEMPOOLSZ);
ck_assert_msg (mempool! = NULL, «Не удалось выделить пул памяти.»);
}

void mp_teardown (недействительно)
{
mempool_free(мемпул);
}

/ * конец пролога * /

#сьют Мемпул

#tcase MP Инициализация

# тест mempool_init_zero_test
мемпул = mempool_init(0);
ck_assert_msg (mempool == NULL, «Выделен пул памяти нулевого размера!»);
ck_assert_msg (mempool_error (), «Не получена ошибка при нулевом распределении.»);

/ * TCase "MP Util" использует проверенную фикстуру. * /
#tcase MP Утилита

#тест mempool_copy_test
void * cp = mempool_copy(мемпул);
ck_assert_msg (cp! = NULL, «Не удалось выполнить копирование пула памяти.»);
ck_assert_msg (cp! = mempool, «Копировать возвращенный исходный указатель!»);

#тест mempool_size_test
ck_assert (мемпул_getsize(мемпул) == MEMPOOLSZ);

# main-pre
tcase_add_checked_fixture (tc1_2, mp_setup, mp_teardown);
srunner_set_log (SR, "mplog.txt");

# главный пост
if (nf! = 0) {
printf ("Эй, что-то не так!% d всех тестов не удалось! \ n", nf);
}
возврат 0; / * Обвязка проверяет вывод, всегда возвращает успех
несмотря на. * /
--------------------------------------------------

Подключив это к чек, мы получим примерно следующий результат:

--------------------------------------------------
/*
* НЕ РЕДАКТИРУЙТЕ ЭТОТ ФАЙЛ. Создано с помощью checkmk.
* Вместо этого отредактируйте исходный исходный файл «всеобъемлющий.ts».
*/

#включают

#include "mempool.h"

void * mempool;

void mp_setup (недействительно)
{
...
}

void mp_teardown (недействительно)
{
...
}

/ * конец пролога * /

START_TEST(mempool_init_zero_test)
{
...
}
END_TEST

START_TEST(mempool_copy_test)
{
...
}
END_TEST

START_TEST(mempool_size_test)
{
...
}
END_TEST

int main (void)
{
Suite * s1 = suite_create ("Мемпул");
TCase * tc1_1 = tcase_create ("MP Init");
TCase * tc1_2 = tcase_create ("MP Util");
SRunner * sr = srunner_create (s1);
инт нф;

/ * Пользовательский код предварительного запуска * /
tcase_add_checked_fixture (tc1_2, mp_setup, mp_teardown);
srunner_set_log (SR, "mplog.txt");

suite_add_tcase (s1, tc1_1);
tcase_add_test (tc1_1, mempool_init_zero_test);
suite_add_tcase (s1, tc1_2);
tcase_add_test (tc1_2, mempool_copy_test);
tcase_add_test (tc1_2, mempool_size_test);

srunner_run_all (SR, CK_ENV);
nf = srunner_ntests_failed (SR);
srunner_free (SR);

/ * Пользовательский код после запуска * /
if (nf! = 0) {
printf ("Эй, что-то не так!% d всех тестов не удалось! \ n", nf);
}
возврат 0; / * Обвязка проверяет вывод, всегда возвращает успех
несмотря на. * /
}
--------------------------------------------------

Используйте checkmk онлайн с помощью сервисов onworks.net