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 si costruiscono i test senza configurare manualmente le opzioni del compilatore?

Usa MakefileWorker.mk di 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:

Come posso generare la copertura del codice?

Abilita: CPPUTEST_USE_GCOV=Y Assicurati che filterGcov.sh sia disponibile in $(CPPUTEST_HOME)/scripts/ . Esegui: make gcov Questo 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.

Introduzione a CppUTest

14 mag 2017

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), e
  - moduli di test utilizzando i blocchi TEST_GROUP e TEST().
- 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)
src/ code/ code.cpp code.h main.cpp t/ main.cpp (test runner) test.cpp (test suite)
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);
return CommandLineTestRunner::RunAllTests(ac, av);
return CommandLineTestRunner::RunAllTests(ac, av);
Come si costruiscono i test senza configurare manualmente le opzioni del compilatore?
Usa MakefileWorker.mk di 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
Memory leak(s) found. Allocated at: code.c line 6 Leak size: 1
Memory leak(s) found. Allocated at: code.c line 6 Leak size: 1
Come posso generare la copertura del codice?
1. Abilita: CPPUTEST_USE_GCOV=Y
2. Assicurati che filterGcov.sh sia disponibile in $(CPPUTEST_HOME)/scripts/.
3. Esegui: make gcov
  Questo 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.

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!

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.

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!

├── 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

// 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!

├── 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

// 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 `-C`	Compila `src/` e delega i test a `t/`
Makefile dei Test	Compila e collega i test con CppUTest	`t/Makefile` che fa riferimento a `MakefileWorker.mk`	Gestisce la compilazione dei test, il collegamento e i flag delle librerie
MakefileWorker.mk	Fornisce logica di build riutilizzabile	Sito nel dir CppUTest `/build`	Aggiunge target: `all`, `clean`, `realclean`, `flags`, `debug`
Integrazione GCov	Abilita la segnalazione della copertura del codice	`CPPUTEST_USE_GCOV=Y`	Produce file `.gcov`, report HTML
Rilevamento delle Perdite di Memoria	Rileva perdite di malloc/free	`CPPUTEST_USE_MEM_LEAK_DETECTION`	Attivo per impostazione predefinita; può essere disabilitato con `=N`
Esecutore dei Test	Esegue gruppi di test	`CommandLineTestRunner`	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.

# 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

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 `-C`	Compila `src/` e delega i test a `t/`
Makefile dei Test	Compila e collega i test con CppUTest	`t/Makefile` che fa riferimento a `MakefileWorker.mk`	Gestisce la compilazione dei test, il collegamento e i flag delle librerie
MakefileWorker.mk	Fornisce logica di build riutilizzabile	Sito nel dir CppUTest `/build`	Aggiunge target: `all`, `clean`, `realclean`, `flags`, `debug`
Integrazione GCov	Abilita la segnalazione della copertura del codice	`CPPUTEST_USE_GCOV=Y`	Produce file `.gcov`, report HTML
Rilevamento delle Perdite di Memoria	Rileva perdite di malloc/free	`CPPUTEST_USE_MEM_LEAK_DETECTION`	Attivo per impostazione predefinita; può essere disabilitato con `=N`
Esecutore dei Test	Esegue gruppi di test	`CommandLineTestRunner`	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.

# 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

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 `-C`	Compila `src/` e delega i test a `t/`
Makefile dei Test	Compila e collega i test con CppUTest	`t/Makefile` che fa riferimento a `MakefileWorker.mk`	Gestisce la compilazione dei test, il collegamento e i flag delle librerie
MakefileWorker.mk	Fornisce logica di build riutilizzabile	Sito nel dir CppUTest `/build`	Aggiunge target: `all`, `clean`, `realclean`, `flags`, `debug`
Integrazione GCov	Abilita la segnalazione della copertura del codice	`CPPUTEST_USE_GCOV=Y`	Produce file `.gcov`, report HTML
Rilevamento delle Perdite di Memoria	Rileva perdite di malloc/free	`CPPUTEST_USE_MEM_LEAK_DETECTION`	Attivo per impostazione predefinita; può essere disabilitato con `=N`
Esecutore dei Test	Esegue gruppi di test	`CommandLineTestRunner`	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

CPPUTEST_USE_GCOV=Y

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

CPPUTEST_USE_GCOV=Y

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

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

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

Altre notizie

Leggi di più da questa categoria

31 mar 2025

Costruire chatbot AI che i clienti vogliono veramente utilizzare

15 ago 2024

Come personalizzare il tuo assistente AI per migliorare il supporto clienti

18 set 2024

Massimizza l'efficienza degli agenti clienti con 11 casi d'uso dell'IA

A person is standing at a desk while typing on a laptop.

La piattaforma completa nativa dell'IA che si espande con la tua azienda.

Contatta le vendite

Inizia gratis

Contatta il supporto

La piattaforma completa nativa dell'IA che si espande con la tua azienda.

Contatta le vendite

Inizia gratis

Contatta il supporto

La piattaforma completa nativa dell'IA che si espande con la tua azienda.

Contatta le vendite

Inizia gratis

Contatta il supporto

Punti Chiave

Punti salienti del Q&A

Che cos'è CppUTest e perché usarlo?

Come strutturi un progetto di base utilizzando CppUTest?

Come esegui tutti i test?

Come si costruiscono i test senza configurare manualmente le opzioni del compilatore?

CppUTest può rilevare perdite di memoria automaticamente?

Come posso generare la copertura del codice?

Cosa può fare CppUTest oltre ai test di base?

Per chi è più adatto CppUTest?

Interessato a saperne di più?

Scaricando CppUTest

Gettare le basi

File di progetto

Test Makefile

Copertura del codice

Rilevamento perdite di memoria Cpputest

Costruire chatbot AI che i clienti vogliono veramente utilizzare

Come personalizzare il tuo assistente AI per migliorare il supporto clienti

Massimizza l'efficienza degli agenti clienti con 11 casi d'uso dell'IA

Costruire chatbot AI che i clienti vogliono veramente utilizzare

Come personalizzare il tuo assistente AI per migliorare il supporto clienti

Massimizza l'efficienza degli agenti clienti con 11 casi d'uso dell'IA

Costruire chatbot AI che i clienti vogliono veramente utilizzare

Come personalizzare il tuo assistente AI per migliorare il supporto clienti

Massimizza l'efficienza degli agenti clienti con 11 casi d'uso dell'IA

Costruire chatbot AI che i clienti vogliono veramente utilizzare

Come personalizzare il tuo assistente AI per migliorare il supporto clienti

Massimizza l'efficienza degli agenti clienti con 11 casi d'uso dell'IA

Costruire chatbot AI che i clienti vogliono veramente utilizzare

Come personalizzare il tuo assistente AI per migliorare il supporto clienti

Massimizza l'efficienza degli agenti clienti con 11 casi d'uso dell'IA

La piattaforma completa nativa dell'IA che si espande con la tua azienda.

Prodotto

Soluzioni

Risorse

Azienda

In arrivo

Sociale

Prodotto

Soluzioni

Risorse

Azienda

In arrivo

Sociale