Unit Testing C Code [chiuso]

Quest'estate ho lavorato su un sistema embedded scritto in chiaro C. Era un progetto esistente che la società per cui lavoro aveva preso il controllo. Mi sono abituato a scrivere unit test in Java usando JUnit ma non sapevo quale sia il modo migliore per scrivere unit test per codice esistente (che necessitava di refactoring) e per aggiungere nuovo codice al sistema.

Ci sono progetti là fuori che rendono il test in codice C semplice come un test in codice Java con JUnit? Qualsiasi approfondimento che si applicherebbe specificamente allo sviluppo integrato (compilazione incrociata su piattaforma arm-linux) sarebbe molto apprezzato.

Un framework di test unitario in C è Check ; un elenco di framework di unit test in C è disponibile qui ed è riprodotto di seguito. A seconda di quante funzioni di libreria standard ha il tuo runtime, potresti non essere in grado di usarne una.

AceUnit

AceUnit (Advanced C e Embedded Unit) si autodefinisce un comodo framework di test per unità di codice C. Cerca di imitare JUnit 4.x e include funzionalità di tipo riflessivo. AceUnit può essere utilizzato in ambienti con vincoli di risorse, ad esempio lo sviluppo di software incorporato, e soprattutto funziona benissimo in ambienti in cui non è possibile includere un singolo file di intestazione standard e non è possibile richiamare una singola funzione C standard dalle librerie C ANSI / ISO. Ha anche una porta di Windows. Non utilizza le forcelle per intrappolare i segnali, sebbene gli autori abbiano espresso interesse per l'aggiunta di tale funzione. Vedi la homepage di AceUnit .

GNU Autounit

Molto simile a Check, incluso il fork per eseguire unit test in uno spazio di indirizzi separato (in effetti, l'autore originale di Check ha preso in prestito l'idea da GNU Autounit). GNU Autounit utilizza GLib ampiamente, il che significa che il collegamento e tali richiedono opzioni speciali, ma questo potrebbe non essere un grosso problema per te, soprattutto se stai già utilizzando GTK o GLib. Vedi la homepage di GNU Autounit .

cunit

Utilizza anche GLib, ma non si biforca per proteggere lo spazio degli indirizzi dei test unitari.

CUnit

Standard C, con piani per un'implementazione della GUI di Win32. Attualmente non effettua il fork o protegge in altro modo lo spazio degli indirizzi dei test unitari. In fase di sviluppo iniziale. Vedi la homepage di CUnit .

Cutest

Un semplice framework con solo un file .c e un file .h che si rilascia nella struttura dei sorgenti. Vedi l' homepage di CuTest .

CppUnit

Il principale framework di unit test per C ++; puoi anche usarlo per testare il codice C. È stabile, attivamente sviluppato e ha un'interfaccia GUI. I motivi principali per non usare CppUnit per C sono in primo luogo che è piuttosto grande, e in secondo luogo devi scrivere i tuoi test in C ++, il che significa che hai bisogno di un compilatore C ++. Se questi non sembrano preoccupazioni, vale sicuramente la pena prendere in considerazione, insieme ad altri framework di test delle unità C ++. Vedi la homepage di CppUnit .

embUnit

embUnit (Embedded Unit) è un altro framework di test unitari per sistemi embedded. Questo sembra essere sostituito da AceUnit. Pagina iniziale dell'unità incorporata .

MinUnit

Un set minimo di macro e basta! Il punto è mostrare quanto sia facile testare l'unità del codice. Vedi la homepage di MinUnit .

Unità per il signor Ando

Un'implementazione di CUnit che è abbastanza nuova e apparentemente ancora in fase di sviluppo iniziale. Vedi la CUnit per la homepage di Mr. Ando .

Questo elenco è stato aggiornato l'ultima volta a marzo 2008.

Più quadri:

CMocka

CMocka è un framework di test per C con supporto per oggetti simulati. È facile da usare e configurare.

Vedi la homepage di CMocka .

Criterio

Criterion è un framework di test di unità C multipiattaforma che supporta la registrazione automatica dei test, i test con parametri, le teorie e che può essere emesso in più formati, inclusi TAP e JUnit XML. Ogni test viene eseguito nel proprio processo, quindi segnali e crash possono essere segnalati o testati se necessario.

Vedi la homepage di Criterion per maggiori informazioni.

HWUT

HWUT è uno strumento di unit test generale con un ottimo supporto per C. Può aiutare a creare Makefile, generare enormi casi di test codificati in 'tabelle di iterazione' minime, camminare su macchine a stati, generare C-stub e altro. L'approccio generale è piuttosto unico: i verdetti si basano su "buono stdout / cattivo stdout". La funzione di confronto, tuttavia, è flessibile. Pertanto, qualsiasi tipo di script può essere utilizzato per il controllo. Può essere applicato a qualsiasi lingua in grado di produrre output standard.

Vedi la homepage di HWUT .

Cgreen

Un framework di test e derisione unitario moderno, portatile e multilingue per C e C ++. Offre una notazione BDD opzionale, una libreria di simulazione, la possibilità di eseguirla in un singolo processo (per semplificare il debug). È disponibile un test runner che scopre automaticamente le funzioni di test. Ma puoi crearne uno tuo a livello di programmazione.

Tutte queste funzionalità (e altro) sono spiegate nel manuale di CGreen .

Wikipedia fornisce un elenco dettagliato dei framework di test delle unità C in Elenco dei framework di test delle unità: C

Personalmente mi piace il framework di test di Google .

La vera difficoltà nel testare il codice C sta nel rompere le dipendenze dai moduli esterni in modo da poter isolare il codice in unità. Ciò può essere particolarmente problematico quando si tenta di ottenere test sul codice legacy. In questo caso mi trovo spesso a utilizzare il linker per utilizzare le funzioni stub nei test.

Questo è ciò a cui le persone si riferiscono quando parlano di " cuciture ". In C la tua unica opzione è davvero quella di utilizzare il pre-processore o il linker per deridere le tue dipendenze.

Una tipica suite di test in uno dei miei progetti C potrebbe apparire così:

#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));
}

Si noti che si sta effettivamente includendo il file C e non il file di intestazione . Ciò offre il vantaggio dell'accesso a tutti i membri di dati statici. Qui prendo in giro il mio logger (che potrebbe essere in logger.o e dare un'implementazione vuota. Ciò significa che il file di test si compila e si collega in modo indipendente dal resto della base di codice ed esegue in modo isolato.

Per quanto riguarda la compilazione incrociata del codice, affinché funzioni, sono necessarie buone strutture per l'obiettivo. L'ho fatto con una croce googletest compilata su Linux su un'architettura PowerPC. Questo ha senso perché lì hai una shell completa e un sistema operativo per raccogliere i tuoi risultati. Per ambienti meno ricchi (che classifico come qualsiasi cosa senza un sistema operativo completo) dovresti semplicemente creare ed eseguire sull'host. Dovresti farlo comunque in modo da poter eseguire i test automaticamente come parte della build.

Trovo che testare il codice C ++ sia generalmente molto più semplice a causa del fatto che il codice OO è generalmente molto meno accoppiato rispetto a quello procedurale (ovviamente questo dipende molto dallo stile di codifica). Anche in C ++ puoi usare trucchi come l'iniezione di dipendenza e l'override del metodo per ottenere cuciture in codice che altrimenti sarebbe incapsulato.

Michael Feathers ha un libro eccellente sul test del codice legacy . In un capitolo tratta le tecniche per trattare il codice non OO che consiglio vivamente.

Modifica : ho scritto un post sul blog sul codice procedurale di unit test, con sorgente disponibile su GitHub .

Modifica : è uscito un nuovo libro dai programmatori pragmatici che affronta in modo specifico il codice C di unit test che consiglio vivamente .

Minunit è un framework di unit test incredibilmente semplice. Lo sto usando per testare il codice del microcontrollore c per avr.

Attualmente sto usando il framework di test dell'unità CuTest:

http://cutest.sourceforge.net/

È ideale per i sistemi embedded poiché è molto leggero e semplice. Non ho avuto problemi a farlo funzionare sia sulla piattaforma di destinazione che sul desktop. Oltre a scrivere i test unitari, tutto ciò che serve è:

• un file di intestazione incluso ovunque tu chiami le routine CuTest
• un singolo file 'C' aggiuntivo da compilare / collegare nell'immagine
• qualche semplice codice aggiunto a main per impostare e chiamare i test unitari - ho solo questo in una speciale funzione main () che viene compilata se UNITTEST viene definito durante la compilazione.

Il sistema deve supportare un heap e alcune funzionalità stdio (che non tutti i sistemi embedded hanno). Ma il codice è abbastanza semplice che potresti probabilmente lavorare in alternativa a quei requisiti se la tua piattaforma non li ha.

Con un uso oculato dei blocchi "C" esterni {} supporta anche il test del C ++.

Dico quasi lo stesso di Ratkok, ma se hai una svolta ai test unitari, allora ...

Unity : framework altamente raccomandato per il codice C di unit testing.

Gli esempi nel libro menzionato in questo thread TDD per C incorporato sono scritti usando Unity (e CppUTest).

Potresti anche dare un'occhiata a libtap , un framework di test C che genera il Test Anything Protocol (TAP) e quindi si integra bene con una varietà di strumenti che escono per questa tecnologia. È utilizzato principalmente nel mondo del linguaggio dinamico, ma è facile da usare e sta diventando molto popolare.

Un esempio:

#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();
}

Esiste un elegante framework di unit test per C con supporto per oggetti similari chiamato cmocka . Richiede solo la libreria C standard, funziona su una vasta gamma di piattaforme di elaborazione (incluso embedded) e con diversi compilatori.

Supporta anche diversi formati di output dei messaggi come i report Subunità, Test Anything Protocol e jUnit XML.

cmocka è stato creato per funzionare anche su piattaforme integrate e ha anche il supporto di Windows.

Un semplice test è simile al seguente:

#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);
}

L' API è completamente documentata e numerosi esempi fanno parte del codice sorgente.

Per iniziare con cmocka dovresti leggere l'articolo su LWN.net: Test unitari con oggetti finti in C

cmocka 1.0 è stato rilasciato nel febbraio 2015.

Non sono andato lontano testando un'applicazione C legacy prima di iniziare a cercare un modo per deridere le funzioni. Avevo bisogno di derisioni per isolare il file C che volevo testare da altri. Ho provato cmock e penso che lo adotterò.

Cmock esegue la scansione dei file di intestazione e genera funzioni simulate in base ai prototipi che trova. Le simulazioni ti permetteranno di testare un file C in perfetto isolamento. Tutto quello che dovrai fare è collegare il tuo file di test con simulazioni invece che con i tuoi file di oggetti reali.

Un altro vantaggio di cmock è che convaliderà i parametri passati a funzioni derise e ti consentirà di specificare quale valore di ritorno dovrebbero fornire i mock. Questo è molto utile per testare diversi flussi di esecuzione nelle tue funzioni.

I test consistono nelle tipiche funzioni testA (), testB () in cui si creano aspettative, si chiamano funzioni per testare e verificare assert.

L'ultimo passo è generare un corridore per i tuoi test con unità. Cmock è legato al framework dei test di unità. Unity è facile da imparare come qualsiasi altro framework di test unitari.

Vale la pena provare e abbastanza facile da capire:

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

Aggiornamento 1

Un altro quadro su cui sto indagando è Cmockery.

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

Si tratta di un framework C puro che supporta test unitari e derisione. Non ha dipendenza dal rubino (contrariamente a Cmock) e ha pochissima dipendenza dalle librerie esterne.

Richiede un po 'più di lavoro manuale per configurare i mock perché non genera codice. Ciò non rappresenta molto lavoro per un progetto esistente poiché i prototipi non cambieranno molto: una volta che hai le tue beffe, non dovrai cambiarle per un po '(questo è il mio caso). La digitazione extra fornisce il controllo completo delle beffe. Se c'è qualcosa che non ti piace, cambi semplicemente la tua derisione.

Non è necessario un test runner speciale. Hai solo bisogno di creare una matrice di test e passarlo a una funzione run_tests. Anche qui un po 'più di lavoro manuale, ma mi piace decisamente l'idea di un framework autonomo autonomo.

Inoltre contiene alcuni trucchi C eleganti che non conoscevo.

Per iniziare, Cmockery ha bisogno di un po 'più di comprensione delle derisioni. Gli esempi dovrebbero aiutarti a superare questo. Sembra che possa fare il lavoro con una meccanica più semplice.

Come principiante in C, ho trovato molto utili le slide chiamate Test driven development in C. Fondamentalmente, utilizza lo standard assert()insieme &&per recapitare un messaggio, senza dipendenze esterne. Se qualcuno è abituato a un framework di test full stack, questo probabilmente non lo farà :)

Abbiamo scritto CHEAT (ospitato su GitHub ) per facilità d'uso e portabilità.

Non ha dipendenze e non richiede installazione o configurazione. Sono necessari solo un file di intestazione e un caso di test.

#include <cheat.h>

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

I test vengono compilati in un eseguibile che si occupa di eseguire i test e di riportarne i risultati.

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

Ha anche dei bei colori.

C'è CUnit

E Embedded Unit è il framework di unit test per il sistema Embedded C. Il suo design è stato copiato da JUnit e CUnit e altri e poi adattato in qualche modo per Embedded C System. L'unità incorporata non richiede librerie C standard. Tutti gli oggetti sono assegnati all'area const.

E Tessy automatizza i test unitari del software incorporato.

Non utilizzo un framework, utilizzo semplicemente il supporto target "check" degli autotools. Implementa un "principale" e usa assert (s).

La mia directory di prova Makefile.am (s) assomiglia a:

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

Il libro di Michael Feather "Lavorare efficacemente con il codice legacy" presenta molte tecniche specifiche per i test unitari durante lo sviluppo C.

Esistono tecniche correlate all'iniezione di dipendenza specifiche di C che non ho visto da nessun'altra parte.

CppUTest : framework altamente raccomandato per il codice C di unit testing.

Gli esempi nel libro menzionato in questo thread TDD per C incorporato sono scritti usando CppUTest.

Uso CxxTest per un ambiente c / c ++ incorporato (principalmente C ++).

Preferisco CxxTest perché ha uno script perl / python per costruire il test runner. Dopo una piccola pendenza per installarlo (ancora più piccolo poiché non è necessario scrivere il test runner), è abbastanza facile da usare (include esempi e documentazione utile). La maggior parte del lavoro consisteva nell'impostare l '"hardware" a cui accede il codice in modo da poter testare l'unità / modulo in modo efficace. Successivamente è facile aggiungere nuovi casi di test unitari.

Come accennato in precedenza, si tratta di un framework di unit test C / C ++. Quindi avrai bisogno di un compilatore C ++.

Guida per l'utente di CxxTest CxxTest Wiki CxxTest

diverso dal mio evidente pregiudizio

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

è un bel modo semplice per testare il codice C. imita xUnit

Dopo aver letto Minunit ho pensato che un modo migliore fosse basare il test sulla macro di assert che uso molto come una tecnica di programma difensiva. Quindi ho usato la stessa idea di Minunit mescolata con affermazione standard. Puoi vedere il mio framework (un buon nome potrebbe essere NoMinunit) nel blog di k0ga

cmockery all'indirizzo http://code.google.com/p/cmockery/

Google ha un eccellente framework di test. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

E sì, per quanto vedo funzionerà con C semplice, cioè non richiede funzionalità C ++ (potrebbe richiedere compilatore C ++, non sono sicuro).

Cmockery è un progetto lanciato di recente che consiste in una libreria C molto semplice da usare per scrivere test unitari.

Per prima cosa, guarda qui: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

La mia azienda ha una libreria C utilizzata dai nostri clienti. Usiamo CxxTest (una libreria di test di unità C ++) per testare il codice. CppUnit funzionerà anche. Se sei bloccato in C, consiglierei RCUNIT (ma CUnit è anche buono).

Se hai familiarità con JUnit, allora consiglio CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Ciò presuppone che tu abbia un compilatore c ++ per eseguire i test unitari. in caso contrario, devo concordare con Adam Rosenfield che il controllo è quello che desideri.

Ho usato RCUNIT per eseguire alcuni test unitari per il codice incorporato su PC prima di testare sul target. Una buona astrazione dell'interfaccia hardware è importante, altrimenti l'endianness e i registri mappati in memoria ti uccideranno.

prova lcut! - http://code.google.com/p/lcut

API Sanity Checker - framework di test per librerie C / C ++:

Un generatore automatico di test unitari di base per una libreria C / C ++ condivisa. È in grado di generare dati di input ragionevoli (nella maggior parte, ma purtroppo non tutti,) per i parametri e comporre casi di test semplici ("sanità mentale" o "superficiale") per ogni funzione nell'API attraverso l'analisi delle dichiarazioni nell'intestazione File.

La qualità dei test generati consente di verificare l'assenza di errori critici in casi d'uso semplici. Lo strumento è in grado di creare ed eseguire test generati e rilevare arresti anomali (segfault), interruzioni, tutti i tipi di segnali emessi, codice di ritorno del programma diverso da zero e blocco del programma.

Esempi:

• Suite di test per fontconfig 2.8.0
• Suite di test per FreeType 2.4.8

Una tecnica da utilizzare è quella di sviluppare il codice unit test con un framework C ++ xUnit (e compilatore C ++), mantenendo allo stesso tempo l'origine del sistema di destinazione come moduli C.

Assicurati di compilare regolarmente la tua sorgente C sotto il tuo compilatore incrociato, automaticamente con i test delle unità, se possibile.

LibU ( http://koanlogic.com/libu ) ha un modulo di unit test che consente esplicite dipendenze di suite / casi di test, isolamento dei test, esecuzione parallela e un formatter di report personalizzabile (i formati predefiniti sono xml e txt).

La libreria ha la licenza BSD e contiene molti altri moduli utili - networking, debug, strutture di dati di uso comune, configurazione, ecc. - se ne avessi bisogno nei tuoi progetti ...

Sono sorpreso che nessuno abbia menzionato Cutter (http://cutter.sourceforge.net/) Puoi testare C e C ++, si integra perfettamente con gli autotools e ha un tutorial davvero carino disponibile.

Nel caso in cui si stia prendendo di mira le piattaforme Win32 o la modalità kernel NT, si dovrebbe dare un'occhiata a cfix .

Se sei ancora a caccia di framework di test, CUnitWin32 è uno per la piattaforma Win32 / NT.

Questo risolve un problema fondamentale che ho dovuto affrontare con altri framework di test. Vale a dire le variabili globali / statiche sono in uno stato deterministico perché ogni test viene eseguito come un processo separato.