checkmk – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

checkmk – Awk-Skript zum Generieren von C-Unit-Tests zur Verwendung mit dem Check-Unit-Test
Rahmen.

ZUSAMMENFASSUNG

checkmk [ clean_mode=1 ] [ Eingabedatei ]

BESCHREIBUNG

Generieren Sie Quelldateien in C-Sprache, die Unit-Tests zur Verwendung mit dem Check-Unit-Test enthalten
Rahmen. Das Ziel dieses Skripts besteht darin, einige der typischen Boilerplate-Skripts zu automatisieren
muss schreiben, wenn eine Testsuite mit Check geschrieben wird: insbesondere die Instanziierung einer
SRunner, Suite(s) und TCase(s) sowie der Aufbau von Beziehungen zwischen diesen Objekten
und die Testfunktionen.

Dieses Tool ist für Personen gedacht, die mit dem Testen von Check-Einheiten vertraut sind
Rahmen. In diesem Handbuch wird davon ausgegangen, dass Sie mit dem Framework vertraut sind.

Das Check-Framework sowie Informationen dazu finden Sie unter
http://check.sourceforge.net/ <URL:http://check.sourceforge.net/>.

Das Eingabedatei Argument zwei checkmk verwendet zur Deklaration eine einfache, C-Präprozessor-ähnliche Syntax
Testfunktionen und um ihre Beziehungen zu Suites und Tcases in Check zu beschreiben.
checkmk Diese Informationen werden dann verwendet, um automatisch eine zu schreiben Main() Funktion, die alles enthält
der erforderlichen Deklarationen und des Codes, der zum Ausführen der Testsuiten erforderlich ist. Der
Die endgültige C-Sprachausgabe wird ausgegeben checkmk's Standardausgabe.

Es stehen Einrichtungen zum Einfügen von Benutzercode in die generierte Datei zur Verfügung Main() Funktion,
um die Verwendung von Protokollierung, Testvorrichtungen oder speziellen Exit-Werten zu ermöglichen.

Es ist zwar möglich, das wegzulassen Eingabedatei Argument zwei checkmk und stellen Sie die Eingabedatei bereit
on checkmkDa es sich stattdessen um die Standardeingabe von handelt, wird im Allgemeinen empfohlen, sie als bereitzustellen
Streit. Dies ermöglicht checkmk den Namen der Datei kennen und darauf verweisen
es in die ersten Kommentare der C-Sprachausgabe einzufügen und C #line-Direktiven einzustreuen
durchgängig, um das Debuggen von Problemen zu erleichtern, indem der Benutzer auf das Original verwiesen wird
Eingabedatei.

OPTIONAL

Die einzige offiziell unterstützte Option ist die Angabe eines wahren Werts (unter Verwendung der Awk-Definition).
für „true“) für die Variable clean_mode. Dies bewirkt checkmk nicht angemessen platzieren
#line-Direktiven im Quellcode, die manche als unnötiges Durcheinander empfinden könnten.

Der Autor rät von der Verwendung dieser Option ab, da sie dazu führt, dass C-Compiler und
Debugging-Tools, um auf Zeilen in der automatisch generierten Ausgabe zu verweisen, anstatt auf die
ursprüngliche Eingabedateien zu checkmk. Dies würde Benutzer dazu ermutigen, die Ausgabedateien zu bearbeiten
anstelle der ursprünglichen Eingabedateien würde es intelligenten Redakteuren erschweren oder
IDEs können dazu führen, dass die richtige Datei zum Bearbeiten aufgerufen wird, was dazu führen kann, dass die Korrekturen überschrieben werden
wenn die Ausgabedateien neu generiert werden.

#line-Direktiven werden automatisch unterdrückt, wenn die Eingabedatei standardmäßig bereitgestellt wird
Eingabe statt als Befehlszeilenargument.

BASIC BEISPIEL

In ihrer einfachsten Form kann eine Eingabedatei lediglich ein Prolog und eine Testfunktion sein.
Alles, was vor der ersten Testfunktion erscheint, ist im Prolog und wird es auch sein
wörtlich in die Ausgabe kopiert. Die Testfunktion beginnt mit einer Zeile in der Form:

#Prüfung Testname

Wo Testname ist der Name Ihrer Testfunktion. Dies wird verwendet, um eine C-Funktion zu benennen,
es muss also ein gültiger C-Bezeichner sein.

Hier ist ein kleines, vollständiges Beispiel:

--------------------------------------------------
/* Ein vollständiges Testbeispiel */

#einschließen

#test the_test
int nc;
const char msg[] = "\n\n Hallo Welt!\n";

nc = printf("%s", msg);
ck_assert(nc == (Größe von(Nachricht) - 1)); /* zum Beenden von NUL. */
--------------------------------------------------

Wenn Sie das Obige in eine Datei mit dem Namen einfügen basic_complete.ts und verarbeiten Sie es mit dem
folgender Befehl:

$ checkmk basic_complete.ts > basic_complete.c

basic_complete.c wird eine Ausgabe ähnlich der folgenden enthalten:

--------------------------------------------------
/*
* DIESE DATEI NICHT BEARBEITEN. Erstellt von checkmk.
* Bearbeiten Sie stattdessen die ursprüngliche Quelldatei „in“.
*/

#enthalten

/* Ein vollständiges Testbeispiel */

#einschließen

START_TEST(the_test)
{
int nc;
const char msg[] = "\n\n Hallo Welt!\n";

nc = printf("%s", msg);
ck_assert(nc == (Größe von(Nachricht) - 1)); /* zum Beenden von NUL. */
}
END_TEST

int Haupt (leer)
{
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);

return nf == 0 ? 0 : 1;
}
--------------------------------------------------

Im realen Gebrauch basic_complete.c würde auch #line-Anweisungen enthalten.

RICHTLINIE ZUSAMMENFASSUNG

Hier finden Sie eine vollständige Zusammenfassung aller Anweisungen im C-Präprozessor-Stil, die verstanden werden
by checkmk. Siehe unten für weitere Details.

# prüfen Testname
# Testsignal(Signal) Testname
# test-exit(Exit_code) Testname
# test-loop(Anfang, Ende) Testname
# test-loop-signal(Signal, Anfang, Ende) Testname
# test-loop-exit(Exit_code, Anfang, Ende) Testname
# Suite TestSuiteName
# tcase Testfallname
# main-pre
# Hauptbeitrag

Bei allen Anweisungen wird die Groß-/Kleinschreibung nicht beachtet. Am Anfang der Zeile können Leerzeichen stehen
vor dem #, zwischen dem # und der Direktive, zwischen der Direktive und einem beliebigen Argument und
am Ende der Zeile.

TESTDEFINIEREND Richtlinien

Hier finden Sie eine detailliertere Erläuterung der Anweisungen, die zum Definieren von Tests verwendet werden können
Funktionen und ihre Container.

TESTEN FUNKTIONEN
# prüfen Testname
# Testsignal(Signal) Testname
# test-exit(Exit_code) Testname
# test-loop(Anfang, Ende) Testname
# test-loop-signal(Signal, Anfang, Ende) Testname
# test-loop-exit(Exit_code, Anfang, Ende) Testname

Dies sind die grundlegendsten Anweisungen zum Erstellen einer Vorlage für die Eingabe checkmk. Sie sind
Die einzigen erforderlichen Anweisungen: Es muss mindestens eine #test*-Anweisung vorhanden sein
in der Vorlage erscheinen, oder checkmk wird mit einer Fehlermeldung fehlschlagen. Der Test*
Anweisungen können mehrmals angegeben werden, wobei jede einzelne mit der Definition eines neuen Tests beginnt
Funktion.

Das Testname Das Argument wird als Name einer Testfunktion in der C-Sprache verwendet
Ausgabe, daher muss es sich um einen gültigen C-Bezeichner handeln. Das heißt, es muss mit einem Alphabet beginnen
Zeichen oder der Unterstrich (_), gefolgt von optionalen alphanumerischen Zeichen und/oder
unterstreicht.

Es sind auch universelle Charakternamen (eingeführt in C99) in der Form \uXXXX oder zulässig
\UXXXXXXXX, wobei die X hexadezimale Ziffern darstellen.

Es ist ein Fehler, dasselbe anzugeben Testname in mehr als einer #test*-Direktive, unabhängig davon
davon, ob sie mit unterschiedlichen Testfällen oder Suiten verknüpft sind.

Unter CHECKMK IDENTIFIERS finden Sie eine Liste der Bezeichner, deren Verwendung als vermieden werden sollte
Testfunktionsnamen.

TESTEN SUITES
# Suite TestSuiteName

Diese Direktive gibt den Namen der Testsuite an (Suiten Objekt im Check-Test
Framework), zu dem alle zukünftigen Testfälle (und deren Testfunktionen) hinzugefügt werden.

Das TestSuiteName ist eine Textzeichenfolge und kann beliebige Zeichen enthalten (andere).
als ASCII-NUL-Zeichen und die neue Zeile, die die Direktive beenden würde). Beliebig
Führende oder nachgestellte Leerzeichen werden im Namen der Testsuite weggelassen.

Durch das Starten einer neuen Testsuite wird auch ein neuer Testfall gestartet, dessen Name mit dem neuen identisch ist
Testsuite. Dieser Testfallname kann durch eine nachfolgende #tcase-Direktive überschrieben werden.

Beachten Sie, dass ein Suiten Objekt wird eigentlich nicht definiert durch checkmk in der C-Ausgabe, es sei denn, es
wird irgendwann von einer #test-Direktive gefolgt (ohne dazwischenliegende #suite). Es ist nicht
ein Fehler, wenn einer #Suite keine #Tests zugeordnet sind; die #suite (und alle damit verbundenen
#tcase's) führt einfach zu keiner Aktion seitens checkmk (und wäre daher
nutzlos).

Es ist ein Fehler, wenn eine #suite-Direktive dasselbe (Groß- und Kleinschreibung beachtende) Suite-Mehrfachangabe angibt
Zeiten, es sei denn, die vorherigen Verwendungen wurden nicht durch die Anwesenheit von mindestens einer instanziiert
zugehörige #test-Direktive.

Wenn Sie vor der ersten #test-Anweisung keine #suite-Anweisung angeben, checkmk
führt das Äquivalent einer impliziten #suite-Direktive mit der Zeichenfolge „Core“ als aus
Wert für TestSuiteName (Dies impliziert auch ein „Kern“-Testfallobjekt). Das ist
oben im GRUNDLEGENDEN BEISPIEL demonstriert.

TESTEN FÄLLE
# tcase Testfallname

Diese Direktive gibt den Namen des Testfalls an (T-Fall Objekt im Check-Test
Framework), zu dem alle zukünftigen Testfunktionen hinzugefügt werden.

Das #tcase funktioniert sehr ähnlich wie #suite. Der Testfallname ist eine Textzeichenfolge,
und kann beliebige Zeichen enthalten; und ein T-Fall Das Objekt wird eigentlich nicht definiert, es sei denn
Es folgt eine zugehörige #test-Direktive.

Es ist ein Fehler, wenn eine #tcase-Direktive denselben Testfall (Groß-/Kleinschreibung beachten) angibt
mehrfach, es sei denn, die vorherigen Verwendungen wurden nicht durch die Anwesenheit von mindestens instanziiert
eine zugehörige #test-Direktive.

Siehe auch die oben beschriebene #suite-Direktive.

USER CODE IN HAUPTSÄCHLICH()

Die C Main() wird automatisch generiert von checkmk, das Notwendige definieren SRunnerist,
Suiten's und T-Fallist für die vom Benutzer angegebenen testdefinierenden Anweisungen erforderlich.

In den meisten Situationen geschieht dies vollständig automatisiert Main() ist so wie es ist durchaus geeignet. Jedoch,
Es gibt Situationen, in denen man benutzerdefinierten Code hinzufügen möchte Main(). Beispielsweise,
wenn der Benutzer Folgendes möchte:

· Ändern Sie den Test-Timeout-Wert über tcase_set_timeout(),

· Geben Sie den „No-Fork-Modus“ von Check über an srunner_set_fork_status(),

· Testvorrichtungen für einige Testfälle einrichten, über tcase_add_checked_fixture()
or tcase_add_unchecked_fixture(),

· Richten Sie die Testprotokollierung für den Suite Runner ein, über srunner_set_log() or srunner_set_xml(), oder

· Führen Sie eine benutzerdefinierte Nachbearbeitung durch, nachdem die Testsuiten ausgeführt wurden.

Zu diesem Zweck wurden die Anweisungen #main-pre und #main-post bereitgestellt.

HAUPTSÄCHLICH() PROLOG
# main-pre

Der auf diese Anweisung folgende Text wird wörtlich in den Hauptteil der generierten Datei eingefügt
Main() Funktion, kurz danach checkmkeigene lokale Variablendeklarationen und vor jedem Test
Das Ausführen hat stattgefunden (in der Tat, bevor überhaupt die Beziehungen zwischen den Tests, test
Fälle und Testsuiten wurden eingerichtet, obwohl diese Tatsache keinen großen Unterschied machen sollte).
Da checkmk erst mit der Abgabe seiner Erklärungen fertig ist, ist es sogar zulässig
unter strengen ISO C-Richtlinien von 1990, um hier benutzerdefinierte Variablendeklarationen vorzunehmen.

Im Gegensatz zu den zuvor beschriebenen Anweisungen darf #main-pre höchstens einmal angegeben werden. Es
Es darf keine #main-post-Direktive und keine #suite-, #tcase- oder #test-Direktive vorangestellt werden
kann danach erscheinen.

#main-pre ist ein guter Ort, um Einstellungen zu optimieren oder Testgeräte einzurichten. Natürlich der Reihe nach
Dazu müssen Sie die Namen kennen checkmk hat verwendet, um das zu instanziieren SRunnerist,
Suiten's und T-Fall'S.

CHECKMK IDENTIFIKATIONEN
Zeiger auf Suiten's werden mit dem Muster s deklariertX, Wobei X ist eine Zahl, die bei beginnt
1 und wird für jede nachfolgende #suite-Anweisung erhöht. s1 existiert immer und
enthält die von der ersten #test-Direktive deklarierte Testfunktion. Wenn diese Richtlinie wäre
Wird kein #suite vorangestellt, erhält es den Namen „Core“.

Zeiger auf T-Fall's werden mit dem Muster tc deklariertX_Y, Wobei X entspricht dem
Nummer, die für den Namen des verwendet wird Suiten das wird das enthalten T-Falleschriebenen Art und Weise; und Y ist eine Zahl, die
beginnt bei 1 für jedes neue Suitenund wird jeweils erhöht T-Fall darin Suiten.

Ein Hinweis darauf SRunner wird mit dem Bezeichner sr deklariert; Es gibt auch eine Ganzzahl mit dem Namen
nf, das die Anzahl der Testfehler enthält (nachdem die Tests ausgeführt wurden).

Aus offensichtlichen Gründen sollte der Benutzer nicht versuchen, lokale Bezeichner in zu deklarieren Main(),
oder definieren Sie Makros oder Testfunktionen, deren Namen möglicherweise mit der lokalen Variablen in Konflikt stehen
Namen, die von verwendet werden checkmk. Zusammenfassend sind diese Namen:

sX

tcX_Y

sr

n.

HAUPTSÄCHLICH() EPILOG
# Hauptbeitrag

Obwohl es nicht so nützlich ist, checkmk Bietet außerdem eine #main-post-Direktive zum Einfügen von benutzerdefinierten
Code am Ende Main(), nachdem die Tests ausgeführt wurden. Dies könnte zum Aufräumen genutzt werden
Ressourcen, die im Prolog zugewiesen wurden, oder um Informationen über die fehlgeschlagenen Ressourcen auszudrucken
Tests durchzuführen oder einen benutzerdefinierten Exit-Statuscode bereitzustellen.

Beachten Sie, dass, wenn Sie von dieser Anweisung Gebrauch machen, checkmk werden wir nicht Geben Sie eine Return-Anweisung an:
Sie müssen selbst eines bereitstellen.

Der #main-post-Anweisung dürfen keine anderen von anerkannten Anweisungen folgen
checkmk.

UMFASSEND BEISPIEL

Nachdem Sie nun die detaillierten Beschreibungen der verschiedenen Anweisungen erhalten haben, werfen wir einen Blick darauf
Mit dieser ziemlich umfassenden Vorlage können Sie alles in die Tat umsetzen.

--------------------------------------------------
#include "mempool.h" /* definiert MEMPOOLSZ, Prototypen für
mempool_init() und mempool_free() */

void *mempool;

void mp_setup(void)
{
mempool = mempool_init(MEMPOOLSZ);
ck_assert_msg(mempool != NULL, „Mempool konnte nicht zugewiesen werden.“);
}

void mp_teardown(void)
{
mempool_free(Speicherpool);
}

/* Ende des Prologs */

#suite Mempool

#tcase MP Init

#test mempool_init_zero_test
mempool = mempool_init(0);
ck_assert_msg(mempool == NULL, „Einen Mempool der Größe Null zugewiesen!“);
ck_assert_msg(mempool_error(), „Es wurde kein Fehler für die Nullzuordnung angezeigt.“);

/* „MP Util“ TCase verwendet aktivierte Fixture. */
#tcase MP Util

#test mempool_copy_test
void *cp = mempool_copy(Speicherpool);
ck_assert_msg(cp != NULL, „Mempool-Kopie konnte nicht durchgeführt werden.“);
ck_assert_msg(cp != mempool, „Zurückgegebenen ursprünglichen Zeiger kopieren!“);

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

#main-pre
tcase_add_checked_fixture(tc1_2, mp_setup, mp_teardown);
srunner_set_log(sr, „mplog.txt“);

#Hauptbeitrag
if (nf != 0) {
printf("Hey, da stimmt etwas nicht! %d ganze Tests sind fehlgeschlagen!\n", nf);
}
0 zurückgeben; /* Harness prüft die Ausgabe, gibt immer Erfolg zurück
trotzdem. */
--------------------------------------------------

Schließen Sie dies an checkmkerhalten wir ungefähr die folgende Ausgabe:

--------------------------------------------------
/*
* DIESE DATEI NICHT BEARBEITEN. Erstellt von checkmk.
* Bearbeiten Sie stattdessen die ursprüngliche Quelldatei „comprehensive.ts“.
*/

#enthalten

#include „mempool.h“

void *mempool;

void mp_setup(void)
{
...
}

void mp_teardown(void)
{
...
}

/* Ende des Prologs */

START_TEST(mempool_init_zero_test)
{
...
}
END_TEST

START_TEST(mempool_copy_test)
{
...
}
END_TEST

START_TEST(mempool_size_test)
{
...
}
END_TEST

int Haupt (leer)
{
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;

/* Vom Benutzer angegebener Vorlaufcode */
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);

/* Vom Benutzer angegebener Post-Run-Code */
if (nf != 0) {
printf("Hey, da stimmt etwas nicht! %d ganze Tests sind fehlgeschlagen!\n", nf);
}
0 zurückgeben; /* Harness prüft die Ausgabe, gibt immer Erfolg zurück
trotzdem. */
}
--------------------------------------------------

Nutzen Sie checkmk online über die Dienste von onworks.net