Unit Testing C Code [geschlossen]

Ich habe diesen Sommer an einem eingebetteten System gearbeitet, das in Straight C geschrieben wurde. Es war ein bestehendes Projekt, das das Unternehmen, für das ich arbeite, übernommen hatte. Ich habe mich ziemlich daran gewöhnt, Unit-Tests in Java mit JUnit zu schreiben, war aber nicht in der Lage, Unit-Tests für vorhandenen Code (der überarbeitet werden musste) sowie neuen Code, der dem System hinzugefügt wurde, am besten zu schreiben.

Gibt es Projekte, die das Testen von einfachem C-Code so einfach machen wie das Testen von Java-Code mit JUnit? Jeder Einblick, der speziell für die Embedded-Entwicklung (Cross-Compiling zur Arm-Linux-Plattform) gelten würde, wäre sehr willkommen.

Ein Unit-Test-Framework in C ist Check . Eine Liste der Unit-Testing-Frameworks in C finden Sie hier und ist unten wiedergegeben. Abhängig davon, wie viele Standardbibliotheksfunktionen Ihre Laufzeit hat, können Sie möglicherweise eine davon verwenden oder nicht.

AceUnit

AceUnit (Advanced C und Embedded Unit) ist ein komfortables Testframework für C-Code-Einheiten. Es versucht, JUnit 4.x nachzuahmen und enthält reflexionsähnliche Funktionen. AceUnit kann in Umgebungen mit Ressourcenbeschränkungen verwendet werden, z. B. in der Entwicklung eingebetteter Software, und funktioniert vor allem in Umgebungen, in denen Sie keine einzelne Standardheaderdatei einschließen und keine einzelne Standard-C-Funktion aus den ANSI / ISO C-Bibliotheken aufrufen können. Es hat auch einen Windows-Port. Es werden keine Gabeln verwendet, um Signale abzufangen, obwohl die Autoren Interesse an der Hinzufügung eines solchen Merkmals bekundet haben. Siehe die AceUnit-Homepage .

GNU Autounit

Ähnlich wie bei Check, einschließlich des Verzweigens, Unit-Tests in einem separaten Adressraum durchzuführen (tatsächlich hat der ursprüngliche Autor von Check die Idee von GNU Autounit ausgeliehen). GNU Autounit verwendet GLib in großem Umfang, was bedeutet, dass für das Verknüpfen und dergleichen spezielle Optionen erforderlich sind. Dies ist jedoch möglicherweise kein großes Problem für Sie, insbesondere wenn Sie bereits GTK oder GLib verwenden. Siehe die GNU Autounit-Homepage .

Einheit

Verwendet auch GLib, bietet jedoch keine Gabelung, um den Adressraum von Komponententests zu schützen.

CUnit

Standard C mit Plänen für eine Win32-GUI-Implementierung. Verzweigt oder schützt den Adressraum von Komponententests derzeit nicht. In der frühen Entwicklung. Siehe die CUnit-Homepage .

CuTest

Ein einfaches Framework mit nur einer .c- und einer .h-Datei, die Sie in Ihren Quellbaum einfügen. Siehe die CuTest-Homepage .

CppUnit

Das führende Unit-Test-Framework für C ++; Sie können es auch zum Testen von C-Code verwenden. Es ist stabil, aktiv entwickelt und verfügt über eine GUI-Oberfläche. Die Hauptgründe, CppUnit für C nicht zu verwenden, sind erstens, dass es ziemlich groß ist, und zweitens müssen Sie Ihre Tests in C ++ schreiben, was bedeutet, dass Sie einen C ++ - Compiler benötigen. Wenn dies nicht nach Bedenken klingt, ist es auf jeden Fall eine Überlegung wert, zusammen mit anderen C ++ - Unit-Test-Frameworks. Siehe die CppUnit-Homepage .

embUnit

embUnit (Embedded Unit) ist ein weiteres Unit-Test-Framework für eingebettete Systeme. Dieser scheint von AceUnit abgelöst zu werden. Homepage der eingebetteten Einheit .

MinUnit

Ein minimaler Satz von Makros und das wars! Der Punkt ist zu zeigen, wie einfach es ist, Ihren Code einem Unit-Test zu unterziehen. Siehe die MinUnit-Homepage .

CUnit für Mr. Ando

Eine CUnit-Implementierung, die ziemlich neu ist und sich offenbar noch in der frühen Entwicklung befindet. Siehe die Homepage von CUnit for Mr. Ando .

Diese Liste wurde zuletzt im März 2008 aktualisiert.

Weitere Frameworks:

CMocka

CMocka ist ein Testframework für C mit Unterstützung für Scheinobjekte. Es ist einfach zu bedienen und einzurichten.

Siehe die CMocka-Homepage .

Kriterium

Criterion ist ein plattformübergreifendes C-Unit-Test-Framework, das die automatische Testregistrierung, parametrisierte Tests und Theorien unterstützt und in mehreren Formaten, einschließlich TAP und JUnit XML, ausgegeben werden kann. Jeder Test wird in einem eigenen Prozess ausgeführt, sodass Signale und Abstürze bei Bedarf gemeldet oder getestet werden können.

Weitere Informationen finden Sie auf der Criterion-Homepage .

HWUT

HWUT ist ein allgemeines Unit-Test-Tool mit hervorragender Unterstützung für C. Es kann helfen, Makefiles zu erstellen, massive Testfälle zu generieren, die in minimalen 'Iterationstabellen' codiert sind, entlang von Zustandsmaschinen zu laufen, C-Stubs zu generieren und vieles mehr. Der allgemeine Ansatz ist ziemlich einzigartig: Urteile basieren auf „gutem Standard / schlechtem Standard“. Die Vergleichsfunktion ist jedoch flexibel. Somit kann jede Art von Skript zur Überprüfung verwendet werden. Es kann auf jede Sprache angewendet werden, die Standardausgaben erzeugen kann.

Siehe die HWUT-Homepage .

CGreen

Ein modernes, portables, sprachübergreifendes Framework zum Testen und Verspotten von Einheiten für C und C ++. Es bietet eine optionale BDD-Notation, eine Verspottungsbibliothek und die Möglichkeit, sie in einem einzigen Prozess auszuführen (um das Debuggen zu vereinfachen). Ein Testläufer, der die Testfunktionen automatisch erkennt, ist verfügbar. Sie können jedoch programmgesteuert Ihre eigenen erstellen.

Alle diese Funktionen (und mehr) werden im CGreen-Handbuch erläutert .

Wikipedia bietet eine detaillierte Liste der C-Unit-Test-Frameworks unter Liste der Unit-Test-Frameworks: C.

Persönlich mag ich das Google Test Framework .

Die eigentliche Schwierigkeit beim Testen von C-Code besteht darin, die Abhängigkeiten von externen Modulen aufzuheben, damit Sie Code in Einheiten isolieren können. Dies kann besonders problematisch sein, wenn Sie versuchen, Tests für Legacy-Code durchzuführen. In diesem Fall verwende ich häufig den Linker, um Stubs-Funktionen in Tests zu verwenden.

Darauf beziehen sich die Leute, wenn sie über " Nähte " sprechen . In C besteht Ihre einzige Option darin, den Vorprozessor oder den Linker zu verwenden, um Ihre Abhängigkeiten zu verspotten.

Eine typische Testsuite in einem meiner C-Projekte könnte folgendermaßen aussehen:

#include "myimplementationfile.c"
#include <gtest/gtest.h>

// Mock out external dependency on mylogger.o
void Logger_log(...){}

TEST(FactorialTest, Zero) {
    EXPECT_EQ(1, Factorial(0));
}

Beachten Sie, dass Sie tatsächlich die C-Datei und nicht die Header-Datei einschließen . Dies bietet den Vorteil des Zugriffs auf alle statischen Datenelemente. Hier verspotte ich meinen Logger (der sich möglicherweise in logger.o befindet und gebe eine leere Implementierung an. Dies bedeutet, dass die Testdatei unabhängig vom Rest der Codebasis kompiliert und verknüpft wird und isoliert ausgeführt wird.

Damit der Code übergreifend kompiliert werden kann, benötigen Sie gute Funktionen für das Ziel, damit dies funktioniert. Ich habe dies mit googletest cross gemacht, das auf einer PowerPC-Architektur unter Linux kompiliert wurde. Dies ist sinnvoll, da Sie dort eine vollständige Shell und ein Betriebssystem haben, um Ihre Ergebnisse zu sammeln. Für weniger umfangreiche Umgebungen (die ich als alles ohne ein vollständiges Betriebssystem klassifiziere) sollten Sie nur auf dem Host erstellen und ausführen. Sie sollten dies trotzdem tun, damit Sie die Tests als Teil des Builds automatisch ausführen können.

Ich finde, dass das Testen von C ++ - Code im Allgemeinen viel einfacher ist, da OO-Code im Allgemeinen viel weniger gekoppelt als prozedural ist (dies hängt natürlich stark vom Codierungsstil ab). Auch in C ++ können Sie Tricks wie Abhängigkeitsinjektion und Methodenüberschreibung verwenden, um Nähte in Code zu bringen, der ansonsten gekapselt ist.

Michael Feathers hat ein ausgezeichnetes Buch über das Testen von Legacy-Code . In einem Kapitel behandelt er Techniken für den Umgang mit Nicht-OO-Code, die ich sehr empfehlen kann.

Bearbeiten : Ich habe einen Blog-Beitrag über Unit-Testing-Verfahrenscode geschrieben, dessen Quelle auf GitHub verfügbar ist .

Bearbeiten : Es gibt ein neues Buch der Pragmatic Programmers , das sich speziell mit Unit-Testing-C-Code befasst, den ich sehr empfehlen kann .

Minunit ist ein unglaublich einfaches Unit-Test-Framework. Ich benutze es, um c Mikrocontroller-Code für avr zu testen.

Ich verwende derzeit das CuTest-Unit-Test-Framework:

http://cutest.sourceforge.net/

Es ist ideal für eingebettete Systeme, da es sehr leicht und einfach ist. Ich hatte keine Probleme damit, dass es sowohl auf der Zielplattform als auch auf dem Desktop funktioniert. Zusätzlich zum Schreiben der Komponententests ist lediglich Folgendes erforderlich:

• Eine Header-Datei, die überall dort enthalten ist, wo Sie die CuTest-Routinen aufrufen
• eine einzelne zusätzliche 'C'-Datei, die kompiliert / mit dem Bild verknüpft werden soll
• Ein einfacher Code, der zu main hinzugefügt wurde, um die Unit-Tests einzurichten und aufzurufen. Ich habe dies nur in einer speziellen main () -Funktion, die kompiliert wird, wenn UNITTEST während des Builds definiert wird.

Das System muss einen Heap und einige Standardfunktionen unterstützen (über die nicht alle eingebetteten Systeme verfügen). Der Code ist jedoch so einfach, dass Sie wahrscheinlich in Alternativen zu diesen Anforderungen arbeiten können, wenn Ihre Plattform diese nicht hat.

Mit einer vernünftigen Verwendung von externen "C" {} -Blöcken wird auch das Testen von C ++ unterstützt.

Ich sage fast das gleiche wie Ratkok, aber wenn Sie eine eingebettete Wendung zu den Unit-Tests haben, dann ...

Unity - Sehr empfehlenswertes Framework zum Testen von C-Code.

Die Beispiele in dem Buch, das in diesem Thread TDD für Embedded C erwähnt wird, wurden mit Unity (und CppUTest) geschrieben.

Vielleicht möchten Sie auch einen Blick auf libtap werfen , ein C- Testframework , das das Test Anything Protocol (TAP) ausgibt und sich daher gut in eine Vielzahl von Tools für diese Technologie integrieren lässt. Es wird hauptsächlich in der dynamischen Sprachwelt verwendet, ist aber einfach zu bedienen und wird immer beliebter.

Ein Beispiel:

#include <tap.h>

int main () {
    plan(5);

    ok(3 == 3);
    is("fnord", "eek", "two different strings not that way?");
    ok(3 <= 8732, "%d <= %d", 3, 8732);
    like("fnord", "f(yes|no)r*[a-f]$");
    cmp_ok(3, ">=", 10);

    done_testing();
}

Es gibt ein elegantes Unit-Testing-Framework für C mit Unterstützung für Scheinobjekte namens cmocka . Es erfordert nur die Standard-C-Bibliothek, funktioniert auf einer Reihe von Computerplattformen (einschließlich Embedded) und mit verschiedenen Compilern.

Es unterstützt auch verschiedene Nachrichtenausgabeformate wie Subunit, Test Anything Protocol und jUnit XML-Berichte.

cmocka wurde entwickelt, um auch auf eingebetteten Plattformen zu funktionieren, und bietet auch Windows-Unterstützung.

Ein einfacher Test sieht folgendermaßen aus:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
    (void) state; /* unused */
}

int main(void) {
    const struct CMUnitTest tests[] = {
        cmocka_unit_test(null_test_success),
    };
    return cmocka_run_group_tests(tests, NULL, NULL);
}

Die API ist vollständig dokumentiert und mehrere Beispiele sind Teil des Quellcodes.

Um mit cmocka zu beginnen, sollten Sie den Artikel auf LWN.net lesen: Unit-Tests mit Scheinobjekten in C.

cmocka 1.0 wurde im Februar 2015 veröffentlicht.

Ich bin nicht weit gekommen, eine ältere C-Anwendung zu testen, bevor ich nach einer Möglichkeit gesucht habe, Funktionen zu verspotten. Ich brauchte dringend Mocks, um die C-Datei, die ich testen möchte, von anderen zu isolieren. Ich habe es mit cmock versucht und ich denke, ich werde es übernehmen.

Cmock scannt Header-Dateien und generiert Mock-Funktionen basierend auf den gefundenen Prototypen. Mit Mocks können Sie eine C-Datei in perfekter Isolation testen. Alles, was Sie tun müssen, ist, Ihre Testdatei mit Mocks anstelle Ihrer realen Objektdateien zu verknüpfen.

Ein weiterer Vorteil von cmock besteht darin, dass Parameter überprüft werden, die an verspottete Funktionen übergeben werden, und dass Sie angeben können, welchen Rückgabewert die Mocks bereitstellen sollen. Dies ist sehr nützlich, um verschiedene Ausführungsabläufe in Ihren Funktionen zu testen.

Tests bestehen aus den typischen Funktionen testA (), testB (), in denen Sie Erwartungen erstellen, Funktionen aufrufen, um Asserts zu testen und zu überprüfen.

Der letzte Schritt besteht darin, einen Läufer für Ihre Tests mit Einheit zu generieren. Cmock ist an das Unity-Test-Framework gebunden. Unity ist so einfach zu erlernen wie jedes andere Unit-Test-Framework.

Einen Versuch wert und ganz einfach zu verstehen:

http://sourceforge.net/apps/trac/cmock/wiki

Update 1

Ein weiteres Framework, das ich untersuche, ist Cmockery.

http://code.google.com/p/cmockery/

Es ist ein reines C-Framework, das Unit-Tests und Verspottungen unterstützt. Es hat keine Abhängigkeit von Ruby (im Gegensatz zu Cmock) und es hat nur eine sehr geringe Abhängigkeit von externen Bibliotheken.

Das Einrichten von Mocks erfordert etwas mehr manuelle Arbeit, da keine Codegenerierung durchgeführt wird. Das bedeutet nicht viel Arbeit für ein bestehendes Projekt, da sich an Prototypen nicht viel ändern wird: Sobald Sie Ihre Verspottungen haben, müssen Sie sie für eine Weile nicht mehr ändern (dies ist mein Fall). Zusätzliche Eingabe bietet vollständige Kontrolle über Mocks. Wenn es etwas gibt, das Sie nicht mögen, ändern Sie einfach Ihren Schein.

Kein spezieller Testläufer erforderlich. Sie müssen nur ein Array von Tests erstellen und an eine Funktion run_tests übergeben. Auch hier etwas mehr manuelle Arbeit, aber ich mag definitiv die Idee eines in sich geschlossenen autonomen Rahmens.

Außerdem enthält es einige raffinierte C-Tricks, die ich nicht kannte.

Insgesamt benötigt Cmockery ein bisschen mehr Verständnis für Mocks, um loszulegen. Beispiele sollen Ihnen helfen, dies zu überwinden. Es sieht so aus, als könnte es die Arbeit mit einfacheren Mechaniken erledigen.

Als C-Neuling fand ich die Folien mit dem Namen Test Driven Development in C sehr hilfreich. Grundsätzlich wird der Standard assert()zusammen mit verwendet &&, um eine Nachricht ohne externe Abhängigkeiten zu übermitteln. Wenn jemand an ein Full-Stack-Test-Framework gewöhnt ist, reicht dies wahrscheinlich nicht aus :)

Wir haben CHEAT (auf GitHub gehostet ) für einfache Benutzerfreundlichkeit und Portabilität geschrieben.

Es hat keine Abhängigkeiten und erfordert keine Installation oder Konfiguration. Es werden nur eine Header-Datei und ein Testfall benötigt.

#include <cheat.h>

CHEAT_TEST(mathematics_still_work,
    cheat_assert(2 + 2 == 4);
    cheat_assert_not(2 + 2 == 5);
)

Tests werden zu einer ausführbaren Datei kompiliert, die sich um die Ausführung der Tests und die Berichterstattung über ihre Ergebnisse kümmert.

$ gcc -I . tests.c
$ ./a.out
..
---
2 successful of 2 run
SUCCESS

Es hat auch schöne Farben.

Es gibt CUnit

Und Embedded Unit ist ein Unit-Test-Framework für das Embedded C-System. Das Design wurde von JUnit und CUnit und mehr kopiert und dann etwas an das Embedded C-System angepasst. Für Embedded Unit sind keine Standard-C-Bibliotheken erforderlich. Alle Objekte sind dem const-Bereich zugeordnet.

Und Tessy automatisiert das Unit-Testen von eingebetteter Software.

Ich verwende kein Framework, sondern nur Autotools, um die Zielunterstützung zu überprüfen. Implementieren Sie ein "main" und verwenden Sie assert (s).

Meine Testverzeichnisse Makefile.am (s) sehen wie folgt aus:

check_PROGRAMS = test_oe_amqp

test_oe_amqp_SOURCES = test_oe_amqp.c
test_oe_amqp_LDADD = -L$(top_builddir)/components/common -loecommon
test_oe_amqp_CFLAGS = -I$(top_srcdir)/components/common -static

TESTS = test_oe_amqp

Michael Feathers Buch "Effektiv mit Legacy-Code arbeiten" enthält viele Techniken, die für Unit-Tests während der C-Entwicklung spezifisch sind.

Es gibt Techniken im Zusammenhang mit der Abhängigkeitsinjektion, die spezifisch für C sind und die ich sonst nirgends gesehen habe.

CppUTest - Sehr empfehlenswertes Framework zum Testen von C-Code.

Die Beispiele in dem Buch, das in diesem Thread TDD für Embedded C erwähnt wird, wurden mit CppUTest geschrieben.

Ich verwende CxxTest für eine eingebettete c / c ++ - Umgebung (hauptsächlich C ++).

Ich bevorzuge CxxTest, weil es ein Perl / Python-Skript zum Erstellen des Testläufers enthält. Nach einer kleinen Steigung, um es einzurichten (noch kleiner, da Sie den Testläufer nicht schreiben müssen), ist es ziemlich einfach zu bedienen (enthält Beispiele und nützliche Dokumentation). Die meiste Arbeit bestand darin, die 'Hardware' einzurichten, auf die der Code zugreift, damit ich den Unit- / Modul-Test effektiv durchführen konnte. Danach ist es einfach, neue Unit-Testfälle hinzuzufügen.

Wie bereits erwähnt, handelt es sich um ein C / C ++ - Unit-Test-Framework. Sie benötigen also einen C ++ - Compiler.

CxxTest Benutzerhandbuch CxxTest Wiki

anders als meine offensichtliche Voreingenommenheit

http://code.google.com/p/seatest/

ist eine schöne einfache Möglichkeit, C-Code zu testen. ahmt xUnit nach

Nachdem ich Minunit gelesen hatte, dachte ich, ein besserer Weg wäre, den Test auf Assert-Makro zu stützen, das ich sehr ähnlich wie die defensive Programmtechnik verwende. Also habe ich die gleiche Idee von Minunit verwendet, gemischt mit Standard-Assert. Sie können mein Framework (ein guter Name könnte NoMinunit sein) in k0gas Blog sehen

cmockery unter http://code.google.com/p/cmockery/

Google verfügt über ein hervorragendes Test-Framework. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

Und ja, soweit ich sehe, funktioniert es mit einfachem C, dh es sind keine C ++ - Funktionen erforderlich (möglicherweise ist ein C ++ - Compiler erforderlich, nicht sicher).

Cmockery ist ein kürzlich gestartetes Projekt, das aus einer sehr einfach zu verwendenden C-Bibliothek zum Schreiben von Komponententests besteht.

Schauen Sie zuerst hier: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

Meine Firma hat eine C-Bibliothek, die unsere Kunden nutzen. Wir verwenden CxxTest (eine C ++ - Unit-Test-Bibliothek), um den Code zu testen. CppUnit funktioniert auch. Wenn Sie in C stecken, würde ich RCUNIT empfehlen (aber CUnit ist auch gut).

Wenn Sie mit JUnit vertraut sind, empfehle ich CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Dies setzt voraus, dass Sie über einen C ++ - Compiler verfügen, um die Komponententests durchzuführen. Wenn nicht, muss ich Adam Rosenfield zustimmen, dass der Scheck das ist, was Sie wollen.

Ich habe RCUNIT verwendet , um einige Unit-Tests für eingebetteten Code auf dem PC durchzuführen , bevor ich das Ziel getestet habe. Eine gute Abstraktion der Hardwareschnittstelle ist wichtig, sonst werden Sie von Endianness und speicherabgebildeten Registern getötet.

versuche es mit lcut! - http://code.google.com/p/lcut

API Sanity Checker - Testframework für C / C ++ - Bibliotheken:

Ein automatischer Generator für grundlegende Komponententests für eine gemeinsam genutzte C / C ++ - Bibliothek. Es ist in der Lage, vernünftige (in den meisten, aber leider nicht allen Fällen) Eingabedaten für Parameter zu generieren und einfache ("vernünftige" oder "flache") Testfälle für jede Funktion in der API durch Analyse der Deklarationen im Header zu erstellen Dateien.

Die Qualität der generierten Tests ermöglicht es, das Fehlen kritischer Fehler in einfachen Anwendungsfällen zu überprüfen. Das Tool ist in der Lage, generierte Tests zu erstellen und auszuführen und Abstürze (Segfaults), Abbrüche, alle Arten von emittierten Signalen, Programm-Rückkehrcode ungleich Null und Programm-Hanging zu erkennen.

Beispiele:

• Testsuite für fontconfig 2.8.0
• Testsuite für FreeType 2.4.8

Eine zu verwendende Technik besteht darin, den Unit-Test-Code mit einem C ++ xUnit-Framework (und einem C ++ - Compiler) zu entwickeln, während die Quelle für das Zielsystem als C-Module beibehalten wird.

Stellen Sie sicher, dass Sie Ihre C-Quelle regelmäßig unter Ihrem Cross-Compiler kompilieren, wenn möglich automatisch mit Ihren Unit-Tests.

LibU ( http://koanlogic.com/libu ) verfügt über ein Unit-Test-Modul, das explizite Abhängigkeiten zwischen Testsuite / Fall, Testisolation, parallele Ausführung und einen anpassbaren Berichtsformatierer ermöglicht (Standardformate sind XML und TXT).

Die Bibliothek ist BSD-lizenziert und enthält viele andere nützliche Module - Netzwerk, Debugging, häufig verwendete Datenstrukturen, Konfiguration usw. - falls Sie diese in Ihren Projekten benötigen ...

Ich bin überrascht, dass niemand Cutter erwähnt hat (http://cutter.sourceforge.net/). Sie können C und C ++ testen, es lässt sich nahtlos in Autotools integrieren und verfügt über ein wirklich schönes Tutorial.

Wenn Sie auf Win32-Plattformen oder den NT-Kernel-Modus abzielen, sollten Sie sich cfix ansehen .

Wenn Sie immer noch auf der Suche nach Test-Frameworks sind, ist CUnitWin32 eines für die Win32 / NT-Plattform.

Dies löst ein grundlegendes Problem, mit dem ich bei anderen Test-Frameworks konfrontiert war. Globale / statische Variablen befinden sich nämlich in einem deterministischen Zustand, da jeder Test als separater Prozess ausgeführt wird.