checkmk - онлайн в хмарі

ПРОГРАМА:

ІМ'Я

checkmk - скрипт Awk для створення модульних тестів C для використання з перевіркою модульного тестування
рамки.

СИНТАКСИС

checkmk [ чистий_режим=1 ] [ вхідний файл ]

ОПИС

Створіть вихідні файли на мові C, що містять модульні тести, для використання з Перевіркою модульного тестування
каркас. Метою цього сценарію є автоматизація деяких типових шаблонів
повинен писати під час написання набору тестів за допомогою Check: зокрема, створення екземпляра an
SRunner, Suite(s) і TCase(s), а також побудова зв'язків між цими об'єктами
і тестові функції.

Цей інструмент призначений для використання тими, хто знайомий з модульним тестуванням Check
каркас. У цьому посібнику передбачається знайомство з структурою.

Структура Check разом з інформацією щодо неї доступна за адресою
http://check.sourceforge.net/ <URL:http://check.sourceforge.net/>.

Команда вхідний файл аргумент до checkmk використовує простий синтаксис, подібний до C-препроцесора для оголошення
тестові функції та описати їх зв’язок із наборами та TCases у Check.
checkmk потім використовує цю інформацію для автоматичного запису a main () функція, що містить усе
необхідних декларацій та будь-якого коду, необхідного для запуску тестових наборів. The
Остаточний вихід на мові C друкується на checkmkстандартний вихід.

Надаються засоби для вставки коду користувача в згенерований main () функція
передбачити використання журналів, контрольних приладів або спеціалізованих вихідних значень.

Хоча можна опустити вхідний файл аргумент до checkmk і надайте вхідний файл
on checkmk' натомість стандартного введення, як правило, рекомендується надавати його як
аргумент. Це дозволяє checkmk знати назву файлу, розміщувати посилання на нього
це в початкових коментарях вихідних даних мовою C, а також для переміщення директив C #line
у всьому, щоб полегшити налагодження проблем, спрямовуючи користувача до оригіналу
вхідний файл.

ВАРІАНТИ

Єдиною офіційно підтримуваною опцією є вказівка ​​справжнього значення (з використанням визначення Awk
для "true") для змінної чистий_режим. Це викликає checkmk не розмістити відповідне
Директиви #line у ​​вихідному коді, які можуть вважатися непотрібними.

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

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

BASIC приклад

У своїй найпростішій формі вхідний файл може бути просто прологом і тестовою функцією.
Все, що з’являється перед першою тестовою функцією, є в пролозі і буде
скопійовано у вихідний текст дослівно. Функція тестування починається з рядка у вигляді:

#test назва_тесту

де назва_тесту це назва вашої тестової функції. Це буде використовуватися для назви функції C,
тому це має бути дійсний ідентифікатор C.

Ось невеликий, повний приклад:

--------------------------------------------------
/* Повний приклад тесту */

#включати

#тестувати_тест
int nc;
const char msg[] = "\n\n Привіт, світ!\n";

nc = printf("%s", повідомлення);
ck_assert(nc == (sizeof(повідомлення) - 1)); /* для припинення NUL. */
--------------------------------------------------

Якщо ви помістите вищевказане у файл з ім basic_complete.ts і обробити його за допомогою
наступна команда:

$ checkmk basic_complete.ts > basic_complete.c

basic_complete.c міститиме вихід, подібний до:

--------------------------------------------------
/*
* НЕ РЕДАГУВАЙТЕ ЦЕЙ ФАЙЛ. Генерується checkmk.
* Натомість відредагуйте вихідний вихідний файл "in".
*/

#включати

/* Повний приклад тесту */

#включати

START_TEST(тест)
{
int nc;
const char msg[] = "\n\n Привіт, світ!\n";

nc = printf("%s", повідомлення);
ck_assert(nc == (sizeof(повідомлення) - 1)); /* для припинення NUL. */
}
END_TEST

int main (недійсний)
{
Suite *s1 = suite_create("Core");
TCase *tc1_1 = tcase_create("Core");
SRunner *sr = srunner_create(s1);
int nf;

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 checkmk. Додаткову інформацію дивіться нижче.

#тест назва_тесту
# тестовий сигнал(сигналізувати) назва_тесту
# тест-вихід(код_виходу) назва_тесту
# тестовий цикл(старт, кінець) назва_тесту
# тест-петля-сигнал(сигналізувати, старт, кінець) назва_тесту
# тест-цикл-вихід(код_виходу, старт, кінець) назва_тесту
# люкс TestSuiteName
# випадок TestCaseName
# основний-попередній
# основний пост

Усі директиви не чутливі до регістру. На початку рядка може з'явитися пробіл
перед #, між # і директивою, між директивою і будь-яким аргументом, і
в кінці рядка.

ТЕСТ-ВИзначення ДИРЕКТИВИ

Ось більш детальне пояснення директив, які можна використовувати для визначення тесту
функції та їх контейнери.

TEST ФУНКЦІЇ
#тест назва_тесту
# тестовий сигнал(сигналізувати) назва_тесту
# тест-вихід(код_виходу) назва_тесту
# тестовий цикл(старт, кінець) назва_тесту
# тест-петля-сигнал(сигналізувати, старт, кінець) назва_тесту
# тест-цикл-вихід(код_виходу, старт, кінець) назва_тесту

Це основні директиви для створення шаблону для введення checkmk. Вони є
єдині обов’язкові директиви: має бути принаймні одна директива #test*
з’являється в шаблоні, або checkmk не вдасться з повідомленням про помилку. Тест*
Директиви можна вказати кілька разів, кожна з яких починає визначення нового тесту
функції.

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

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

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

Перелік ідентифікаторів, яких слід уникати для використання як, див. CHECKMK IDENTIFIERS
назви тестових функцій.

TEST ЛЮКС
# люкс TestSuiteName

Ця директива визначає назву набору тестів (Набір об'єкт у тесті Перевірка
фреймворк), до якого будуть додані всі майбутні тестові випадки (та їх тестові функції).

Команда TestSuiteName є текстовим рядком і може містити будь-які символи (інші
ніж символ ASCII NUL, і новий рядок, який завершить дію директиви). Будь-який
провідні або кінцеві пробіли будуть опущені з назви набору тестів.

Запуск нового набору тестів також розпочинає новий тестовий приклад, ім’я якого збігається з новим
тестовий набір. Ця назва тестового прикладу може бути замінена наступною директивою #tcase.

Зауважте, що a Набір об’єкт фактично не буде визначений checkmk у виводі C, якщо не
в якийсь момент слідує директива #test (без проміжного #suite). Це не
помилка, коли #набір не має пов'язаних #test's; #suite (і будь-які пов’язані
#tcase's) просто не призведе до жодних дій з боку checkmk (і, отже, буде
марно).

Для директиви #suite є помилкою вказувати один і той самий (з урахуванням регістру) кілька наборів
разів, за винятком випадків, коли попереднє використання не було визначено наявністю принаймні одного
пов'язана директива #test.

Якщо ви не вкажете директиву #suite перед першою директивою #test, checkmk
виконує еквівалент неявної директиви #suite з рядком "Core" як
значення для TestSuiteName (це також має на увазі об'єкт тестового випадку "Core"). Це
показано вище в ОСНОВНОМУ ПРИКЛАДІ.

TEST ВИПАДКИ
# випадок TestCaseName

Ця директива визначає назву тестового випадку (TCase об'єкт у тесті Перевірка
framework), до якого будуть додані всі майбутні функції тестування.

#tcase працює дуже схожим на #suite. The TestCaseName це текстовий рядок,
і може містити довільні символи; і а TCase об’єкт насправді не буде визначено, якщо
за нею йде пов'язана директива #test.

Для директиви #tcase є помилкою вказувати той самий тестовий приклад (з урахуванням регістру).
кілька разів, якщо попереднє використання не було ініційовано наявністю принаймні
одна пов'язана директива #test.

Дивіться також описану вище директиву #suite.

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

С main () автоматично генерується за допомогою checkmk, визначаючи необхідне SRRunner's,
Набірі, і TCase' вимагають директиви, що визначають тест, визначені користувачем.

У більшості ситуацій це повністю автоматизовано main () цілком підходить як є. однак,
Існують ситуації, коли можна додати власний код до файлу main (). Наприклад,
якщо користувач бажає:

· змінити значення тайм-ауту тесту через tcase_set_timeout(),

· вказати «режим без вилки» Чека через srunner_set_fork_status(),

· налаштувати тестові прилади для деяких тестових випадків, через tcase_add_checked_fixture()
or tcase_add_unchecked_fixture(),

· налаштувати протоколювання тестів для пакета Runner, через srunner_set_log() or srunner_set_xml()або

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

Для цих цілей надано директиви #main-pre і #main-post.

ГОЛОВНИЙ() ПРОЛОГ
# основний-попередній

Текст, що слідує за цією директивою, буде дослівно розміщено в тілі згенерованого
main () функція, відразу після checkmkвласне оголошення локальних змінних перед будь-яким тестом
запуск відбувся (справді, ще до того, як зв’язки між тестами, test
кейси та набори тестів створено, хоча цей факт не має особливої ​​різниці).
З checkmk щойно закінчив робити свої заяви, це навіть дозволено
відповідно до строгих інструкцій ISO C 1990 року, щоб зробити тут оголошення користувацьких змінних.

На відміну від описаних раніше директив, #main-pre можна вказати щонайбільше один раз. Це
не може передувати директива #main-post, а також директива #suite, #tcase або #test
може з'явитися після нього.

#main-pre — це гарне місце для налаштування налаштувань або налаштування тестових приладів. Звісно, ​​по порядку
для цього потрібно знати, які імена checkmk використовував для створення екземпляра SRRunner's,
Набірі, і TCase's.

CHECKMK ІДЕНТИФІКАТОРИ
Вказує на Набір's оголошуються за допомогою шаблону sX, Де X це число, яке починається з
1 і збільшується для кожної наступної директиви #suite. s1 завжди існує, і
містить тестову функцію, оголошену першою директивою #test. Якби ця директива була
не передує #suite, йому буде присвоєно назву "Core".

Вказує на TCase's оголошуються за допомогою шаблону tcX_Y, Де X відповідає
номер, який використовується для назви Набір який буде містити це TCaseІ Y це число, яке
починається з 1 для кожного нового Набір, і збільшується для кожного TCase у цьому Набір.

Вказівник на SRRunner оголошується за допомогою ідентифікатора sr; також є ціле число з ім'ям
nf, який містить кількість невдач тестів (після виконання тестів).

З очевидних причин користувачеві не слід намагатися оголошувати локальні ідентифікатори main (),
або визначити будь-які макроси або тестові функції, імена яких можуть конфліктувати з локальною змінною
назви, які використовуються checkmk. Підсумовуючи, це назви:

sX

tcX_Y

sr

п.

ГОЛОВНИЙ() ЕПІЛОГ
# основний пост

Хоча це не так корисно, checkmk також містить директиву #main-post для вставки користувацького
код в кінці main (), після запуску тестів. Це можна використати для очищення
ресурсів, які були виділені в пролозі, або для друку інформації про невдалих
тестів або надати користувацький код статусу виходу.

Зауважте, що, якщо ви скористаєтеся цією директивою, checkmk волі НЕ надати заяву про повернення:
вам потрібно буде надати його самостійно.

За директивою #main-post не можуть слідувати будь-які інші директиви, визнані
checkmk.

СКЛАДНИЙ приклад

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

--------------------------------------------------
#include "mempool.h" /* визначає MEMPOOLSZ, прототипи для
mempool_init() і mempool_free() */

void *mempool;

void mp_setup(void)
{
mempool = mempool_init(MEMPOOLSZ);
ck_assert_msg(mempool != NULL, "Не вдалося виділити mempool.");
}

void mp_teardown(void)
{
mempool_free(мемпул);
}

/* кінець прологу */

#люкс Мемпул

#tcase MP Init

#test mempool_init_zero_test
mempool = mempool_init(0);
ck_assert_msg(mempool == NULL, "Виділили мемпул нульового розміру!");
ck_assert_msg(mempool_error(), "Не отримано помилку для нульового розподілу.");

/* TCase "MP Util" використовує перевірений прилад. */
#tcase MP Util

#test mempool_copy_test
порожня *cp = mempool_copy(мемпул);
ck_assert_msg(cp != NULL, "Не вдалося виконати копіювання мемпулу.");
ck_assert_msg(cp != mempool, "Копіювати повернутий вихідний покажчик!");

#test mempool_size_test
ck_assert(mempool_getsize(mempool) == MEMPOOLSZ);

#основний-попередній
tcase_add_checked_fixture(tc1_2, mp_setup, mp_teardown);
srunner_set_log(sr, "mplog.txt");

#головний пост
якщо (nf != 0) {
printf("Гей, щось не так! %d цілих тестів не вдалося!\n", nf);
}
повернути 0; /* Перевіряє вихід, завжди повертає успіх
незалежно від того. */
--------------------------------------------------

Підключивши це checkmk, ми отримаємо приблизно такий результат:

--------------------------------------------------
/*
* НЕ РЕДАГУВАЙТЕ ЦЕЙ ФАЙЛ. Генерується checkmk.
* Натомість відредагуйте вихідний файл "comprehensive.ts".
*/

#включати

#include "mempool.h"

void *mempool;

void mp_setup(void)
{
...
}

void mp_teardown(void)
{
...
}

/* кінець прологу */

START_TEST(mempool_init_zero_test)
{
...
}
END_TEST

START_TEST(mempool_copy_test)
{
...
}
END_TEST

START_TEST(mempool_size_test)
{
...
}
END_TEST

int main (недійсний)
{
Suite *s1 = suite_create("Mempool");
TCase *tc1_1 = tcase_create("MP Init");
TCase *tc1_2 = tcase_create("MP Util");
SRunner *sr = srunner_create(s1);
int nf;

/* Вказаний користувачем код попереднього запуску */
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);

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

Використовуйте checkmk онлайн за допомогою служб onworks.net