Introduzione a CppUTest
Uccello
14 mag 2017
1 min read
Punti Chiave
CppUTest è un framework di test leggero e attivamente mantenuto in stile xUnit per C/C++, con uno strato di integrazione C che funziona senza problemi anche in codebase pesanti in C.
Puoi installarlo tramite gestori di pacchetti (distribuzioni Linux, Homebrew) o clonare il repository GitHub.
Un'installazione minima consiste in:
una directory di produzione
src/,una directory di test
t/,un runner di test (
CommandLineTestRunner), emoduli di test utilizzando i blocchi
TEST_GROUPeTEST().
CppUTest fornisce un helper MakefileWorker.mk che semplifica la creazione di test, il collegamento delle librerie e la gestione dei flag.
La rilevazione delle perdite di memoria è abilitata per impostazione predefinita tramite sovrascritture malloc/free, catturando le perdite all'interno del codice sorgente testato.
La copertura del codice tramite gcov si integra facilmente abilitando
CPPUTEST_USE_GCOV=Y, producendo report di copertura completi e sommari HTML.Il framework include funzionalità avanzate: mocking, plugin, script di aiuto e interoperabilità diretta con C — utili per codebase aziendali complesse.
Punti salienti del Q&A
Che cos'è CppUTest e perché usarlo?
È un robusto framework di testing in stile xUnit per C/C++ con un'API pulita, macro di asserzione integrate, rilevamento delle perdite e sviluppo attivo — ideale per sistemi legacy o moderni.
Come strutturi un progetto di base utilizzando CppUTest?
src/ code/ code.cpp code.h main.cpp t/ main.cpp (test runner) test.cpp (test suite)
Come esegui tutti i test?
Il runner del test utilizza:
return CommandLineTestRunner::RunAllTests(ac, av);
Come si costruiscono i test senza configurare manualmente le opzioni del compilatore?
Usa
MakefileWorker.mkdi CppUTest, che gestisce automaticamente le flag, il linking e l'esecuzione dei test.CppUTest può rilevare perdite di memoria automaticamente?
Sì. Sovrascrive malloc/free durante le costruzioni di test, segnalando:
quale test ha causato la perdita,
dove è avvenuta,
dimensione della perdita e contenuti di memoria.
Esempio di output di errore:
Memory leak(s) found. Allocated at: code.c line 6 Leak size: 1
Come posso generare la copertura del codice?
Abilita:
CPPUTEST_USE_GCOV=YAssicurati che
filterGcov.shsia disponibile in$(CPPUTEST_HOME)/scripts/.Esegui: make
gcovQuesto produce
.gcov, testo di riepilogo e rapporti di copertura HTML.
Cosa può fare CppUTest oltre ai test di base?
framework di mocking
sistema di plugin
script di automazione helper
integrazione nativa con C
macro di affermazione estese
Per chi è più adatto CppUTest?
Le squadre che lavorano con sistemi integrati, piattaforme C, servizi C++ o qualsiasi ambiente in cui l'affidabilità e la sicurezza della memoria devono essere continuamente validate.
In SparkPost, dedichiamo molto tempo e impegno per testare il nostro codice. La nostra piattaforma è scritta in C e recentemente ho ricercato come integrare un framework di unit testing chiamato “CppUTest”, che fornisce test in stile xUnit per C/C++. Questo framework è robusto, ricco di funzionalità e in fase di sviluppo attivo, il che lo rende una scelta eccellente. Fornisce anche uno strato di integrazione C che lo rende facile da usare con il nostro codice C della piattaforma, anche se la maggior parte del framework è in C++. Questo tutorial tratta di come iniziare a utilizzare CppUTest nei tuoi progetti.
In SparkPost, dedichiamo molto tempo e impegno per testare il nostro codice. La nostra piattaforma è scritta in C e recentemente ho ricercato come integrare un framework di unit testing chiamato “CppUTest”, che fornisce test in stile xUnit per C/C++. Questo framework è robusto, ricco di funzionalità e in fase di sviluppo attivo, il che lo rende una scelta eccellente. Fornisce anche uno strato di integrazione C che lo rende facile da usare con il nostro codice C della piattaforma, anche se la maggior parte del framework è in C++. Questo tutorial tratta di come iniziare a utilizzare CppUTest nei tuoi progetti.
In SparkPost, dedichiamo molto tempo e impegno per testare il nostro codice. La nostra piattaforma è scritta in C e recentemente ho ricercato come integrare un framework di unit testing chiamato “CppUTest”, che fornisce test in stile xUnit per C/C++. Questo framework è robusto, ricco di funzionalità e in fase di sviluppo attivo, il che lo rende una scelta eccellente. Fornisce anche uno strato di integrazione C che lo rende facile da usare con il nostro codice C della piattaforma, anche se la maggior parte del framework è in C++. Questo tutorial tratta di come iniziare a utilizzare CppUTest nei tuoi progetti.
Interessato a saperne di più?
Questo è solo la punta dell'iceberg per quanto riguarda tutte le funzionalità contenute in questo strumento. Oltre alle basi discusse qui, include anche un framework di mocking, un layer di integrazione C diretto e un framework di plugin, per citarne alcune significative. Il repository contiene anche un'intera directory di script di supporto che possono aiutare ad automatizzare alcune delle parti di routine nel lavoro con il framework.
Spero che le informazioni qui ti aiutino a migliorare la qualità del tuo codice C/C++ con questo fantastico strumento!
Questo è solo la punta dell'iceberg per quanto riguarda tutte le funzionalità contenute in questo strumento. Oltre alle basi discusse qui, include anche un framework di mocking, un layer di integrazione C diretto e un framework di plugin, per citarne alcune significative. Il repository contiene anche un'intera directory di script di supporto che possono aiutare ad automatizzare alcune delle parti di routine nel lavoro con il framework.
Spero che le informazioni qui ti aiutino a migliorare la qualità del tuo codice C/C++ con questo fantastico strumento!
Questo è solo la punta dell'iceberg per quanto riguarda tutte le funzionalità contenute in questo strumento. Oltre alle basi discusse qui, include anche un framework di mocking, un layer di integrazione C diretto e un framework di plugin, per citarne alcune significative. Il repository contiene anche un'intera directory di script di supporto che possono aiutare ad automatizzare alcune delle parti di routine nel lavoro con il framework.
Spero che le informazioni qui ti aiutino a migliorare la qualità del tuo codice C/C++ con questo fantastico strumento!
Scaricando CppUTest
La pagina del progetto CppUTest è disponibile sul sito ufficiale, e il repository è su github. È anche incluso nei repository di gestione dei pacchetti per molte distro linux, così come in homebrew su Mac OS. Gli esempi che seguono sono stati eseguiti su Mac OS X, ma derivano da codice scritto per Red Hat, il sistema operativo su cui gira la nostra piattaforma.
Le basi sono ben documentate sulla pagina principale di CppUTest. Ci passeremo velocemente e arriveremo ad alcune delle caratteristiche più interessanti.
La pagina del progetto CppUTest è disponibile sul sito ufficiale, e il repository è su github. È anche incluso nei repository di gestione dei pacchetti per molte distro linux, così come in homebrew su Mac OS. Gli esempi che seguono sono stati eseguiti su Mac OS X, ma derivano da codice scritto per Red Hat, il sistema operativo su cui gira la nostra piattaforma.
Le basi sono ben documentate sulla pagina principale di CppUTest. Ci passeremo velocemente e arriveremo ad alcune delle caratteristiche più interessanti.
La pagina del progetto CppUTest è disponibile sul sito ufficiale, e il repository è su github. È anche incluso nei repository di gestione dei pacchetti per molte distro linux, così come in homebrew su Mac OS. Gli esempi che seguono sono stati eseguiti su Mac OS X, ma derivano da codice scritto per Red Hat, il sistema operativo su cui gira la nostra piattaforma.
Le basi sono ben documentate sulla pagina principale di CppUTest. Ci passeremo velocemente e arriveremo ad alcune delle caratteristiche più interessanti.
Gettare le basi
Prima di tutto, iniziamo a scrivere un po' di codice!
Il nostro progetto di test avrà un file ‘main’ e includerà una libreria di utilità chiamata ‘code’. La libreria fornirà una semplice funzione che restituisce 1 (per ora). I file saranno disposti in questo modo:
├── src │ ├── code │ │ ├── code.cpp │ │ └── code.h │ └── main.cpp └── t ├── main.cpp └── test.cpp
Iniziamo scrivendo i file src/
// src/main.cpp #include <stdlib.h> #include <stdio.h> #include "code.h" int main(void) { test_func(); printf("hello world!\n"); exit(0); }
// src/code/code.cpp #include <stdlib.h> #include "code.h" int test_func() { return 1; }
// src/code/code.h #ifndef __code_h__ #define __code_h__ int test_func(); #endif
Ora, facciamo i test, che si trovano nella directory t/. La prima cosa da fare è impostare un test runner che eseguirà i nostri file di test. Questa è anche la funzione ‘main’ che verrà eseguita una volta che tutto sarà compilato:
// t/main.cpp #include "CppUTest/CommandLineTestRunner.h" int main(int ac, char** av) { return CommandLineTestRunner::RunAllTests(ac, av); }
Ora possiamo scrivere il nostro primo modulo di test:
// t/test.cpp #include "CppUTest/TestHarness.h" #include "code.h" TEST_GROUP(AwesomeExamples) { }; TEST(AwesomeExamples, FirstExample) { int x = test_func(); CHECK_EQUAL(1, x); }
Successivamente, dobbiamo scrivere i makefile. Ne avremo bisogno di due: uno per i file di progetto sotto src/, e uno per i test.
Prima di tutto, iniziamo a scrivere un po' di codice!
Il nostro progetto di test avrà un file ‘main’ e includerà una libreria di utilità chiamata ‘code’. La libreria fornirà una semplice funzione che restituisce 1 (per ora). I file saranno disposti in questo modo:
├── src │ ├── code │ │ ├── code.cpp │ │ └── code.h │ └── main.cpp └── t ├── main.cpp └── test.cpp
Iniziamo scrivendo i file src/
// src/main.cpp #include <stdlib.h> #include <stdio.h> #include "code.h" int main(void) { test_func(); printf("hello world!\n"); exit(0); }
// src/code/code.cpp #include <stdlib.h> #include "code.h" int test_func() { return 1; }
// src/code/code.h #ifndef __code_h__ #define __code_h__ int test_func(); #endif
Ora, facciamo i test, che si trovano nella directory t/. La prima cosa da fare è impostare un test runner che eseguirà i nostri file di test. Questa è anche la funzione ‘main’ che verrà eseguita una volta che tutto sarà compilato:
// t/main.cpp #include "CppUTest/CommandLineTestRunner.h" int main(int ac, char** av) { return CommandLineTestRunner::RunAllTests(ac, av); }
Ora possiamo scrivere il nostro primo modulo di test:
// t/test.cpp #include "CppUTest/TestHarness.h" #include "code.h" TEST_GROUP(AwesomeExamples) { }; TEST(AwesomeExamples, FirstExample) { int x = test_func(); CHECK_EQUAL(1, x); }
Successivamente, dobbiamo scrivere i makefile. Ne avremo bisogno di due: uno per i file di progetto sotto src/, e uno per i test.
Prima di tutto, iniziamo a scrivere un po' di codice!
Il nostro progetto di test avrà un file ‘main’ e includerà una libreria di utilità chiamata ‘code’. La libreria fornirà una semplice funzione che restituisce 1 (per ora). I file saranno disposti in questo modo:
├── src │ ├── code │ │ ├── code.cpp │ │ └── code.h │ └── main.cpp └── t ├── main.cpp └── test.cpp
Iniziamo scrivendo i file src/
// src/main.cpp #include <stdlib.h> #include <stdio.h> #include "code.h" int main(void) { test_func(); printf("hello world!\n"); exit(0); }
// src/code/code.cpp #include <stdlib.h> #include "code.h" int test_func() { return 1; }
// src/code/code.h #ifndef __code_h__ #define __code_h__ int test_func(); #endif
Ora, facciamo i test, che si trovano nella directory t/. La prima cosa da fare è impostare un test runner che eseguirà i nostri file di test. Questa è anche la funzione ‘main’ che verrà eseguita una volta che tutto sarà compilato:
// t/main.cpp #include "CppUTest/CommandLineTestRunner.h" int main(int ac, char** av) { return CommandLineTestRunner::RunAllTests(ac, av); }
Ora possiamo scrivere il nostro primo modulo di test:
// t/test.cpp #include "CppUTest/TestHarness.h" #include "code.h" TEST_GROUP(AwesomeExamples) { }; TEST(AwesomeExamples, FirstExample) { int x = test_func(); CHECK_EQUAL(1, x); }
Successivamente, dobbiamo scrivere i makefile. Ne avremo bisogno di due: uno per i file di progetto sotto src/, e uno per i test.
File di progetto
Il makefile del progetto sarà allo stesso livello delle directory ‘src’ e ‘t’ alla radice del progetto. Dovrebbe apparire così:
# Makefile SRC_DIR = ./src CODE_DIR = $(SRC_DIR)/code OUT = example TEST_DIR = t test: make -C $(TEST_DIR) test_clean: make -C $(TEST_DIR) clean code.o: gcc -c -I$(CODE_DIR) $(CODE_DIR)/code.cpp -o $(CODE_DIR)/code.o main: code.o gcc -I$(CODE_DIR) $(CODE_DIR)/code.o $(SRC_DIR)/main.cpp -o $(OUT) all: test main clean: test_clean rm $(SRC_DIR)/*.o $(CODE_DIR)/*.o $(OUT)
Nota che questo utilizza ‘make -C’ per i target di test – il che significa che chiamerà ‘make’ di nuovo utilizzando il makefile nella directory di test.
A questo punto possiamo compilare il codice ‘src’ con il makefile e vedere che funziona:
[]$ make main gcc -c -I./src/code ./src/code/code.cpp -o ./src/code/code.o gcc -I./src/code ./src/code/code.o ./src/main.cpp -o example []$ ./example hello world
Il makefile del progetto sarà allo stesso livello delle directory ‘src’ e ‘t’ alla radice del progetto. Dovrebbe apparire così:
# Makefile SRC_DIR = ./src CODE_DIR = $(SRC_DIR)/code OUT = example TEST_DIR = t test: make -C $(TEST_DIR) test_clean: make -C $(TEST_DIR) clean code.o: gcc -c -I$(CODE_DIR) $(CODE_DIR)/code.cpp -o $(CODE_DIR)/code.o main: code.o gcc -I$(CODE_DIR) $(CODE_DIR)/code.o $(SRC_DIR)/main.cpp -o $(OUT) all: test main clean: test_clean rm $(SRC_DIR)/*.o $(CODE_DIR)/*.o $(OUT)
Nota che questo utilizza ‘make -C’ per i target di test – il che significa che chiamerà ‘make’ di nuovo utilizzando il makefile nella directory di test.
A questo punto possiamo compilare il codice ‘src’ con il makefile e vedere che funziona:
[]$ make main gcc -c -I./src/code ./src/code/code.cpp -o ./src/code/code.o gcc -I./src/code ./src/code/code.o ./src/main.cpp -o example []$ ./example hello world
Il makefile del progetto sarà allo stesso livello delle directory ‘src’ e ‘t’ alla radice del progetto. Dovrebbe apparire così:
# Makefile SRC_DIR = ./src CODE_DIR = $(SRC_DIR)/code OUT = example TEST_DIR = t test: make -C $(TEST_DIR) test_clean: make -C $(TEST_DIR) clean code.o: gcc -c -I$(CODE_DIR) $(CODE_DIR)/code.cpp -o $(CODE_DIR)/code.o main: code.o gcc -I$(CODE_DIR) $(CODE_DIR)/code.o $(SRC_DIR)/main.cpp -o $(OUT) all: test main clean: test_clean rm $(SRC_DIR)/*.o $(CODE_DIR)/*.o $(OUT)
Nota che questo utilizza ‘make -C’ per i target di test – il che significa che chiamerà ‘make’ di nuovo utilizzando il makefile nella directory di test.
A questo punto possiamo compilare il codice ‘src’ con il makefile e vedere che funziona:
[]$ make main gcc -c -I./src/code ./src/code/code.cpp -o ./src/code/code.o gcc -I./src/code ./src/code/code.o ./src/main.cpp -o example []$ ./example hello world
Test Makefile
Per i test, le cose sono un po' più complesse poiché dobbiamo caricare e integrare correttamente la libreria CppUTest.
Il repository di CppUTest fornisce un file chiamato “MakefileWorker.mk”. Fornisce molte funzionalità che rendono semplice la costruzione con CppUTest. Il file si trova nella directory “build” nel repository git. Per questo tutorial supporremo che sia stato copiato nella directory ‘t/’. Può essere utilizzato come segue:
# we don’t want to use relative paths, so we set these variables PROJECT_DIR=/path/to/project SRC_DIR=$(PROJECT_DIR)/src TEST_DIR=$(PROJECT_DIR)/t # specify where the source code and includes are located INCLUDE_DIRS=$(SRC_DIR)/code SRC_DIRS=$(SRC_DIR)/code # specify where the test code is located TEST_SRC_DIRS=$(TEST_DIR) # what to call the test binary TEST_TARGET=example # where the cpputest library is located CPPUTEST_HOME=/usr/local # run MakefileWorker.mk with the variables defined here include MakefileWorker.mk
Nota che CPPUTEST_HOME deve essere impostato su dove CppUTest è stato installato. Se hai installato un pacchetto di distribuzione, questo si troverà tipicamente sotto /usr/local in un sistema linux/mac. Se hai scaricato il repository da solo, si trova dove si trova quel checkout.
Queste opzioni sono tutte documentate in MakefileWorker.mk.
MakefileWorker.mk aggiunge anche alcuni target makefile, inclusi i seguenti:
all – costruisce i test indicati dal makefile
clean – rimuove tutti i file oggetto e gcov generati per i test
realclean – rimuove eventuali file oggetto o gcov nell'intero albero delle directory
flags – elenca tutti i flag configurati utilizzati per compilare i test
debug – elenca tutti i file sorgente, oggetti, dipendenze e ‘cose da pulire’
Componente | Scopo | File / Flag Chiave | Note |
|---|---|---|---|
Makefile del Progetto | Compila il codice sorgente di base | Makefile a livello root usando make | Compila |
Makefile dei Test | Compila e collega i test con CppUTest |
| Gestisce la compilazione dei test, il collegamento e i flag delle librerie |
MakefileWorker.mk | Fornisce logica di build riutilizzabile | Sito nel dir CppUTest | Aggiunge target: |
Integrazione GCov | Abilita la segnalazione della copertura del codice |
| Produce file |
Rilevamento delle Perdite di Memoria | Rileva perdite di malloc/free |
| Attivo per impostazione predefinita; può essere disabilitato con |
Esecutore dei Test | Esegue gruppi di test |
| Punto di ingresso principale necessario per eseguire i test |
Per i test, le cose sono un po' più complesse poiché dobbiamo caricare e integrare correttamente la libreria CppUTest.
Il repository di CppUTest fornisce un file chiamato “MakefileWorker.mk”. Fornisce molte funzionalità che rendono semplice la costruzione con CppUTest. Il file si trova nella directory “build” nel repository git. Per questo tutorial supporremo che sia stato copiato nella directory ‘t/’. Può essere utilizzato come segue:
# we don’t want to use relative paths, so we set these variables PROJECT_DIR=/path/to/project SRC_DIR=$(PROJECT_DIR)/src TEST_DIR=$(PROJECT_DIR)/t # specify where the source code and includes are located INCLUDE_DIRS=$(SRC_DIR)/code SRC_DIRS=$(SRC_DIR)/code # specify where the test code is located TEST_SRC_DIRS=$(TEST_DIR) # what to call the test binary TEST_TARGET=example # where the cpputest library is located CPPUTEST_HOME=/usr/local # run MakefileWorker.mk with the variables defined here include MakefileWorker.mk
Nota che CPPUTEST_HOME deve essere impostato su dove CppUTest è stato installato. Se hai installato un pacchetto di distribuzione, questo si troverà tipicamente sotto /usr/local in un sistema linux/mac. Se hai scaricato il repository da solo, si trova dove si trova quel checkout.
Queste opzioni sono tutte documentate in MakefileWorker.mk.
MakefileWorker.mk aggiunge anche alcuni target makefile, inclusi i seguenti:
all – costruisce i test indicati dal makefile
clean – rimuove tutti i file oggetto e gcov generati per i test
realclean – rimuove eventuali file oggetto o gcov nell'intero albero delle directory
flags – elenca tutti i flag configurati utilizzati per compilare i test
debug – elenca tutti i file sorgente, oggetti, dipendenze e ‘cose da pulire’
Componente | Scopo | File / Flag Chiave | Note |
|---|---|---|---|
Makefile del Progetto | Compila il codice sorgente di base | Makefile a livello root usando make | Compila |
Makefile dei Test | Compila e collega i test con CppUTest |
| Gestisce la compilazione dei test, il collegamento e i flag delle librerie |
MakefileWorker.mk | Fornisce logica di build riutilizzabile | Sito nel dir CppUTest | Aggiunge target: |
Integrazione GCov | Abilita la segnalazione della copertura del codice |
| Produce file |
Rilevamento delle Perdite di Memoria | Rileva perdite di malloc/free |
| Attivo per impostazione predefinita; può essere disabilitato con |
Esecutore dei Test | Esegue gruppi di test |
| Punto di ingresso principale necessario per eseguire i test |
Per i test, le cose sono un po' più complesse poiché dobbiamo caricare e integrare correttamente la libreria CppUTest.
Il repository di CppUTest fornisce un file chiamato “MakefileWorker.mk”. Fornisce molte funzionalità che rendono semplice la costruzione con CppUTest. Il file si trova nella directory “build” nel repository git. Per questo tutorial supporremo che sia stato copiato nella directory ‘t/’. Può essere utilizzato come segue:
# we don’t want to use relative paths, so we set these variables PROJECT_DIR=/path/to/project SRC_DIR=$(PROJECT_DIR)/src TEST_DIR=$(PROJECT_DIR)/t # specify where the source code and includes are located INCLUDE_DIRS=$(SRC_DIR)/code SRC_DIRS=$(SRC_DIR)/code # specify where the test code is located TEST_SRC_DIRS=$(TEST_DIR) # what to call the test binary TEST_TARGET=example # where the cpputest library is located CPPUTEST_HOME=/usr/local # run MakefileWorker.mk with the variables defined here include MakefileWorker.mk
Nota che CPPUTEST_HOME deve essere impostato su dove CppUTest è stato installato. Se hai installato un pacchetto di distribuzione, questo si troverà tipicamente sotto /usr/local in un sistema linux/mac. Se hai scaricato il repository da solo, si trova dove si trova quel checkout.
Queste opzioni sono tutte documentate in MakefileWorker.mk.
MakefileWorker.mk aggiunge anche alcuni target makefile, inclusi i seguenti:
all – costruisce i test indicati dal makefile
clean – rimuove tutti i file oggetto e gcov generati per i test
realclean – rimuove eventuali file oggetto o gcov nell'intero albero delle directory
flags – elenca tutti i flag configurati utilizzati per compilare i test
debug – elenca tutti i file sorgente, oggetti, dipendenze e ‘cose da pulire’
Componente | Scopo | File / Flag Chiave | Note |
|---|---|---|---|
Makefile del Progetto | Compila il codice sorgente di base | Makefile a livello root usando make | Compila |
Makefile dei Test | Compila e collega i test con CppUTest |
| Gestisce la compilazione dei test, il collegamento e i flag delle librerie |
MakefileWorker.mk | Fornisce logica di build riutilizzabile | Sito nel dir CppUTest | Aggiunge target: |
Integrazione GCov | Abilita la segnalazione della copertura del codice |
| Produce file |
Rilevamento delle Perdite di Memoria | Rileva perdite di malloc/free |
| Attivo per impostazione predefinita; può essere disabilitato con |
Esecutore dei Test | Esegue gruppi di test |
| Punto di ingresso principale necessario per eseguire i test |
Copertura del codice
I test unitari non sarebbero completi senza un rapporto di copertura. Lo strumento di riferimento per questo per i progetti che utilizzano gcc è gcov, disponibile come parte della suite standard di utility gcc. Cpputest si integra facilmente con gcov, tutto ciò che devi fare è aggiungere questa riga al makefile:
CPPUTEST_USE_GCOV=Y
Successivamente, dobbiamo assicurarci che lo script filterGcov.sh da questo repo si trovi in ‘/scripts/filterGcov.sh’ relativamente a ovunque tu abbia impostato ‘CPPUTEST_HOME’. Deve anche avere i permessi di esecuzione.
Nell'esempio di Makefile, dovrebbe essere distribuito in ‘/usr/local/scripts/filterGcov.sh’. Se stai eseguendo CppUTest da un checkout del repository, tutto dovrebbe funzionare senza modifiche.
Con questo in atto, puoi semplicemente eseguire ‘make gcov’ e l'analisi verrà generata per te. Nel nostro caso, dovremo eseguire ‘make -B’ per ricostruire i file oggetto con gcov abilitato:
[]$ make -B gcov < compilation output > for d in /Users/ykuperman/code/blogpost/qa/src/code ; do \ FILES=`ls $d/*.c $d/*.cc $d/*.cpp 2> /dev/null` ; \ gcov --object-directory objs/$d $FILES >> gcov_output.txt 2>>gcov_error.txt ; \ done for f in ; do \ gcov --object-directory objs/$f $f >> gcov_output.txt 2>>gcov_error.txt ; \ done /usr/local/scripts/filterGcov.sh gcov_output.txt gcov_error.txt gcov_report.txt example.txt cat gcov_report.txt 100.00% /Users/ykuperman/code/blogpost/qa/src/code/code.cpp mkdir -p gcov mv *.gcov gcov mv gcov_* gcov See gcov directory for details
Questo genererà un numero di file in una nuova directory ‘gcov’. Questi sono:
code.cpp.gcov – il file ‘gcov’ effettivo per il codice sottoposto a test
gcov_error.txt – un rapporto di errore (nel nostro caso, dovrebbe essere vuoto)
gcov_output.txt – il reale output del comando gcov che è stato eseguito
gcov_report.txt – un riepilogo della copertura per ciascun file sottoposto a test
gcov_report.txt.html – una versione html di gcov_report
I test unitari non sarebbero completi senza un rapporto di copertura. Lo strumento di riferimento per questo per i progetti che utilizzano gcc è gcov, disponibile come parte della suite standard di utility gcc. Cpputest si integra facilmente con gcov, tutto ciò che devi fare è aggiungere questa riga al makefile:
CPPUTEST_USE_GCOV=Y
Successivamente, dobbiamo assicurarci che lo script filterGcov.sh da questo repo si trovi in ‘/scripts/filterGcov.sh’ relativamente a ovunque tu abbia impostato ‘CPPUTEST_HOME’. Deve anche avere i permessi di esecuzione.
Nell'esempio di Makefile, dovrebbe essere distribuito in ‘/usr/local/scripts/filterGcov.sh’. Se stai eseguendo CppUTest da un checkout del repository, tutto dovrebbe funzionare senza modifiche.
Con questo in atto, puoi semplicemente eseguire ‘make gcov’ e l'analisi verrà generata per te. Nel nostro caso, dovremo eseguire ‘make -B’ per ricostruire i file oggetto con gcov abilitato:
[]$ make -B gcov < compilation output > for d in /Users/ykuperman/code/blogpost/qa/src/code ; do \ FILES=`ls $d/*.c $d/*.cc $d/*.cpp 2> /dev/null` ; \ gcov --object-directory objs/$d $FILES >> gcov_output.txt 2>>gcov_error.txt ; \ done for f in ; do \ gcov --object-directory objs/$f $f >> gcov_output.txt 2>>gcov_error.txt ; \ done /usr/local/scripts/filterGcov.sh gcov_output.txt gcov_error.txt gcov_report.txt example.txt cat gcov_report.txt 100.00% /Users/ykuperman/code/blogpost/qa/src/code/code.cpp mkdir -p gcov mv *.gcov gcov mv gcov_* gcov See gcov directory for details
Questo genererà un numero di file in una nuova directory ‘gcov’. Questi sono:
code.cpp.gcov – il file ‘gcov’ effettivo per il codice sottoposto a test
gcov_error.txt – un rapporto di errore (nel nostro caso, dovrebbe essere vuoto)
gcov_output.txt – il reale output del comando gcov che è stato eseguito
gcov_report.txt – un riepilogo della copertura per ciascun file sottoposto a test
gcov_report.txt.html – una versione html di gcov_report
I test unitari non sarebbero completi senza un rapporto di copertura. Lo strumento di riferimento per questo per i progetti che utilizzano gcc è gcov, disponibile come parte della suite standard di utility gcc. Cpputest si integra facilmente con gcov, tutto ciò che devi fare è aggiungere questa riga al makefile:
CPPUTEST_USE_GCOV=Y
Successivamente, dobbiamo assicurarci che lo script filterGcov.sh da questo repo si trovi in ‘/scripts/filterGcov.sh’ relativamente a ovunque tu abbia impostato ‘CPPUTEST_HOME’. Deve anche avere i permessi di esecuzione.
Nell'esempio di Makefile, dovrebbe essere distribuito in ‘/usr/local/scripts/filterGcov.sh’. Se stai eseguendo CppUTest da un checkout del repository, tutto dovrebbe funzionare senza modifiche.
Con questo in atto, puoi semplicemente eseguire ‘make gcov’ e l'analisi verrà generata per te. Nel nostro caso, dovremo eseguire ‘make -B’ per ricostruire i file oggetto con gcov abilitato:
[]$ make -B gcov < compilation output > for d in /Users/ykuperman/code/blogpost/qa/src/code ; do \ FILES=`ls $d/*.c $d/*.cc $d/*.cpp 2> /dev/null` ; \ gcov --object-directory objs/$d $FILES >> gcov_output.txt 2>>gcov_error.txt ; \ done for f in ; do \ gcov --object-directory objs/$f $f >> gcov_output.txt 2>>gcov_error.txt ; \ done /usr/local/scripts/filterGcov.sh gcov_output.txt gcov_error.txt gcov_report.txt example.txt cat gcov_report.txt 100.00% /Users/ykuperman/code/blogpost/qa/src/code/code.cpp mkdir -p gcov mv *.gcov gcov mv gcov_* gcov See gcov directory for details
Questo genererà un numero di file in una nuova directory ‘gcov’. Questi sono:
code.cpp.gcov – il file ‘gcov’ effettivo per il codice sottoposto a test
gcov_error.txt – un rapporto di errore (nel nostro caso, dovrebbe essere vuoto)
gcov_output.txt – il reale output del comando gcov che è stato eseguito
gcov_report.txt – un riepilogo della copertura per ciascun file sottoposto a test
gcov_report.txt.html – una versione html di gcov_report
Rilevamento perdite di memoria Cpputest
Cpputest ti consente di rilevare automaticamente la memoria persa ridefinendo la famiglia di funzioni standard “malloc/free” per utilizzare invece i propri wrapper. Questo consente di catturare rapidamente le perdite e rapportarle per ogni esecuzione del test. Questo è abilitato per default in MakefileWorker.mk, quindi è già attivo con i passaggi descritti finora.
Per illustrare, facciamo perdere un po' di memoria in test_func() !
Tornando a code.c, aggiungiamo un malloc() alla funzione, in questo modo:
int test_func() { malloc(1); return 1; }
Ora, dopo la ricompilazione, viene prodotto il seguente errore:
test.cpp:9: error: Failure in TEST(AwesomeExamples, FirstExample) Memory leak(s) found. Alloc num (4) Leak size: 1 Allocated at: ./code.c and line: 6 Type: "malloc" Memory: <
Questo mostra quale test ha causato la perdita, dove è avvenuta la perdita nel codice sorgente e cosa c'era nella memoria persa. Molto utile!
Ci sono un paio di avvertenze su questa funzionalità:
Cpputest utilizza macro preprocessore per ridefinire dinamicamente tutte le chiamate alle funzioni standard di gestione della memoria. Ciò significa che funzionerà solo per le chiamate nel codice sorgente in test poiché è ciò che viene compilato con le sovrapposizioni di CppUTest. Le perdite nelle librerie collegate non verranno rilevate.
A volte la memoria che viene allocata per l'intera durata del processo non deve essere liberata. Questo può generare molti errori invasivi se stai testando un modulo con questo comportamento. Per disabilitare il rilevamento delle perdite, puoi fare così:
CPPUTEST_USE_MEM_LEAK_DETECTION=N
Cpputest ti consente di rilevare automaticamente la memoria persa ridefinendo la famiglia di funzioni standard “malloc/free” per utilizzare invece i propri wrapper. Questo consente di catturare rapidamente le perdite e rapportarle per ogni esecuzione del test. Questo è abilitato per default in MakefileWorker.mk, quindi è già attivo con i passaggi descritti finora.
Per illustrare, facciamo perdere un po' di memoria in test_func() !
Tornando a code.c, aggiungiamo un malloc() alla funzione, in questo modo:
int test_func() { malloc(1); return 1; }
Ora, dopo la ricompilazione, viene prodotto il seguente errore:
test.cpp:9: error: Failure in TEST(AwesomeExamples, FirstExample) Memory leak(s) found. Alloc num (4) Leak size: 1 Allocated at: ./code.c and line: 6 Type: "malloc" Memory: <
Questo mostra quale test ha causato la perdita, dove è avvenuta la perdita nel codice sorgente e cosa c'era nella memoria persa. Molto utile!
Ci sono un paio di avvertenze su questa funzionalità:
Cpputest utilizza macro preprocessore per ridefinire dinamicamente tutte le chiamate alle funzioni standard di gestione della memoria. Ciò significa che funzionerà solo per le chiamate nel codice sorgente in test poiché è ciò che viene compilato con le sovrapposizioni di CppUTest. Le perdite nelle librerie collegate non verranno rilevate.
A volte la memoria che viene allocata per l'intera durata del processo non deve essere liberata. Questo può generare molti errori invasivi se stai testando un modulo con questo comportamento. Per disabilitare il rilevamento delle perdite, puoi fare così:
CPPUTEST_USE_MEM_LEAK_DETECTION=N
Cpputest ti consente di rilevare automaticamente la memoria persa ridefinendo la famiglia di funzioni standard “malloc/free” per utilizzare invece i propri wrapper. Questo consente di catturare rapidamente le perdite e rapportarle per ogni esecuzione del test. Questo è abilitato per default in MakefileWorker.mk, quindi è già attivo con i passaggi descritti finora.
Per illustrare, facciamo perdere un po' di memoria in test_func() !
Tornando a code.c, aggiungiamo un malloc() alla funzione, in questo modo:
int test_func() { malloc(1); return 1; }
Ora, dopo la ricompilazione, viene prodotto il seguente errore:
test.cpp:9: error: Failure in TEST(AwesomeExamples, FirstExample) Memory leak(s) found. Alloc num (4) Leak size: 1 Allocated at: ./code.c and line: 6 Type: "malloc" Memory: <
Questo mostra quale test ha causato la perdita, dove è avvenuta la perdita nel codice sorgente e cosa c'era nella memoria persa. Molto utile!
Ci sono un paio di avvertenze su questa funzionalità:
Cpputest utilizza macro preprocessore per ridefinire dinamicamente tutte le chiamate alle funzioni standard di gestione della memoria. Ciò significa che funzionerà solo per le chiamate nel codice sorgente in test poiché è ciò che viene compilato con le sovrapposizioni di CppUTest. Le perdite nelle librerie collegate non verranno rilevate.
A volte la memoria che viene allocata per l'intera durata del processo non deve essere liberata. Questo può generare molti errori invasivi se stai testando un modulo con questo comportamento. Per disabilitare il rilevamento delle perdite, puoi fare così:
CPPUTEST_USE_MEM_LEAK_DETECTION=N
