Prise en main avec CppUTest

Email

·

14 mai 2017

Prise en main avec CppUTest

Points Clés

    • CppUTest est un framework de test de style xUnit léger et activement maintenu pour C/C++, avec une couche d'intégration C qui fonctionne parfaitement même dans les bases de code lourdes en C.

    • Vous pouvez l'installer via les gestionnaires de paquets (distributions Linux, Homebrew) ou cloner le dépôt GitHub.

    • Une configuration minimale se compose de :

      • un répertoire de production src/,

      • un répertoire de tests t/,

      • un exécuteur de tests (CommandLineTestRunner), et

      • des modules de test utilisant les blocs TEST_GROUP et TEST().

    • CppUTest fournit un assistant MakefileWorker.mk qui simplifie la compilation des tests, l'édition de liens avec les bibliothèques, et la gestion des indicateurs.

    • La détection des fuites de mémoire est activée par défaut grâce aux remplacements de malloc/free, capturant les fuites au sein du code source testé.

    • La couverture de code via gcov s'intègre facilement en activant CPPUTEST_USE_GCOV=Y, en produisant des rapports de couverture complets et des résumés HTML.

    • Le framework inclut des fonctionnalités avancées : moquerie, plugins, scripts d'aide, et interopérabilité directe avec C — utile pour les bases de code d'entreprise complexes.

Points forts des Q&A

  • Qu'est-ce que CppUTest et pourquoi l'utiliser ?

    C'est un cadre de test robuste de style xUnit pour C/C++ avec une API propre, des macros d'assertion intégrées, une détection des fuites et un développement actif — idéal pour les systèmes hérités ou modernes.

  • Comment structurer un projet de base en utilisant 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)

  • Comment exécutez-vous tous les tests ?

    Le test runner utilise :

    return CommandLineTestRunner::RunAllTests(ac, av);
    return CommandLineTestRunner::RunAllTests(ac, av);
    return CommandLineTestRunner::RunAllTests(ac, av);

  • Comment construire des tests sans configurer manuellement les options du compilateur ?

    Utilisez MakefileWorker.mk de CppUTest, qui gère automatiquement les indicateurs, le lien et l'exécution des tests.

  • CppUTest peut-il détecter les fuites de mémoire automatiquement ?

    Oui. Cela remplace malloc/free lors des constructions de test, rapportant :

    • quel test a fui,

    • où cela s'est produit,

    • la taille de la fuite et le contenu de la mémoire.

    Exemple de sortie d'échec :

    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

  • Comment générer un code coverage ?

    1. Activer : CPPUTEST_USE_GCOV=Y

    2. Assurez-vous que filterGcov.sh est disponible à $(CPPUTEST_HOME)/scripts/.

    3. Exécuter : make gcov

      Cela produit des rapports de couverture .gcov, un résumé en texte, et des rapports de couverture HTML.

  • Que peut faire CppUTest d'autre au-delà des tests de base ?

    • système de simulation

    • système de plugins

    • scripts d'automatisation d'assistance

    • intégration native C

    • macros d'assertion étendues

  • Who is CppUTest best suited for?

    Équipes travaillant avec des systèmes embarqués, des plateformes C, des services C++, ou tout environnement où la fiabilité et la sécurité mémoire doivent être continuellement validées.

Chez SparkPost, nous consacrons beaucoup de temps et d'efforts à tester notre code. Notre plateforme est écrite en C, et récemment, j'ai recherché l'intégration avec un framework de test unitaire appelé "CppUTest", qui fournit des tests de style xUnit pour C/C++. Ce framework est robuste, riche en fonctionnalités et en développement actif, ce qui en fait un excellent choix. Il offre également une couche d'intégration C qui rend son utilisation facile avec notre code C de plateforme même si la plupart du framework est en C++. Ce tutoriel couvre comment commencer avec CppUTest sur vos propres projets.

Intéressé par More ?

Ceci n'est que la partie émergée de l'iceberg en ce qui concerne toutes les fonctionnalités contenues dans cet outil. Outre les bases discutées ici, il comprend également un cadre de simulation, une couche d'intégration C directe et un cadre de plugin, pour n'en nommer que quelques-uns parmi les plus importants. Le repo contient également un répertoire complet de scripts d'assistance qui peuvent aider à automatiser certaines des parties routinières du travail avec le framework.

J'espère que les informations ici vous aideront à améliorer la qualité de votre code C/C++ avec cet excellent outil !

Téléchargement de CppUTest

La page du projet CppUTest est disponible sur le site officiel, et le dépôt est sur github. Il est également inclus dans les référentiels de gestion des paquets pour de nombreuses distributions Linux, ainsi que homebrew sur Mac OS. Les exemples qui suivent ont été exécutés sur Mac OS X, mais ils sont dérivés du code écrit pour Red Hat, le système d'exploitation sur lequel notre plateforme fonctionne.

Les bases sont bien documentées sur la page d'accueil de CppUTest. Nous allons survoler cela et passer à certaines des fonctionnalités les plus intéressantes.

Poser les bases

Tout d'abord, écrivons du code !

Notre projet de test aura un fichier 'main' et inclura une bibliothèque utilitaire appelée 'code'. La bibliothèque fournira une fonction simple qui retourne 1 (pour l'instant). Les fichiers seront organisés comme ceci :

├── src
│   ├── code
│   │   ├── code.cpp
│   │   └── code.h
│   └── main.cpp
└── t
    ├── main.cpp
    └── test.cpp

Commençons par écrire les fichiers 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

Maintenant, faisons les tests, qui seront dans le répertoire t/.  La première chose à faire est de mettre en place un exécuteur de tests qui exécutera nos fichiers de test. C'est aussi la fonction 'main' qui s'exécutera une fois que tout cela sera compilé :

// t/main.cpp
#include "CppUTest/CommandLineTestRunner.h"
int main(int ac, char** av) {
return CommandLineTestRunner::RunAllTests(ac, av);
}

Nous pouvons maintenant écrire notre premier module de 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);
}

Ensuite, nous devons écrire des makefiles.  Nous en aurons besoin de deux : un pour les fichiers du projet sous src/, et un pour les tests.

Tout d'abord, écrivons du code !

Notre projet de test aura un fichier 'main' et inclura une bibliothèque utilitaire appelée 'code'. La bibliothèque fournira une fonction simple qui retourne 1 (pour l'instant). Les fichiers seront organisés comme ceci :

├── src
│   ├── code
│   │   ├── code.cpp
│   │   └── code.h
│   └── main.cpp
└── t
    ├── main.cpp
    └── test.cpp

Commençons par écrire les fichiers 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

Maintenant, faisons les tests, qui seront dans le répertoire t/.  La première chose à faire est de mettre en place un exécuteur de tests qui exécutera nos fichiers de test. C'est aussi la fonction 'main' qui s'exécutera une fois que tout cela sera compilé :

// t/main.cpp
#include "CppUTest/CommandLineTestRunner.h"
int main(int ac, char** av) {
return CommandLineTestRunner::RunAllTests(ac, av);
}

Nous pouvons maintenant écrire notre premier module de 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);
}

Ensuite, nous devons écrire des makefiles.  Nous en aurons besoin de deux : un pour les fichiers du projet sous src/, et un pour les tests.

Tout d'abord, écrivons du code !

Notre projet de test aura un fichier 'main' et inclura une bibliothèque utilitaire appelée 'code'. La bibliothèque fournira une fonction simple qui retourne 1 (pour l'instant). Les fichiers seront organisés comme ceci :

├── src
│   ├── code
│   │   ├── code.cpp
│   │   └── code.h
│   └── main.cpp
└── t
    ├── main.cpp
    └── test.cpp

Commençons par écrire les fichiers 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

Maintenant, faisons les tests, qui seront dans le répertoire t/.  La première chose à faire est de mettre en place un exécuteur de tests qui exécutera nos fichiers de test. C'est aussi la fonction 'main' qui s'exécutera une fois que tout cela sera compilé :

// t/main.cpp
#include "CppUTest/CommandLineTestRunner.h"
int main(int ac, char** av) {
return CommandLineTestRunner::RunAllTests(ac, av);
}

Nous pouvons maintenant écrire notre premier module de 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);
}

Ensuite, nous devons écrire des makefiles.  Nous en aurons besoin de deux : un pour les fichiers du projet sous src/, et un pour les tests.

Projet Makefile

Le makefile du projet sera au même niveau que les répertoires ‘src’ et ‘t’ à la racine du projet. Il devrait ressembler à ceci :

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

Notez que cela utilise ‘make -C’ pour les cibles de test – ce qui signifie qu’il appellera ‘make’ à nouveau en utilisant le makefile dans le répertoire de test.

À ce stade, nous pouvons compiler le code ‘src’ avec le makefile et vérifier que cela fonctionne :

[]$ 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

Le makefile du projet sera au même niveau que les répertoires ‘src’ et ‘t’ à la racine du projet. Il devrait ressembler à ceci :

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

Notez que cela utilise ‘make -C’ pour les cibles de test – ce qui signifie qu’il appellera ‘make’ à nouveau en utilisant le makefile dans le répertoire de test.

À ce stade, nous pouvons compiler le code ‘src’ avec le makefile et vérifier que cela fonctionne :

[]$ 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

Le makefile du projet sera au même niveau que les répertoires ‘src’ et ‘t’ à la racine du projet. Il devrait ressembler à ceci :

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

Notez que cela utilise ‘make -C’ pour les cibles de test – ce qui signifie qu’il appellera ‘make’ à nouveau en utilisant le makefile dans le répertoire de test.

À ce stade, nous pouvons compiler le code ‘src’ avec le makefile et vérifier que cela fonctionne :

[]$ 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

Tests Makefile

Pour les tests, les choses sont un peu plus compliquées car nous devons correctement charger et intégrer la bibliothèque CppUTest.

Le dépôt CppUTest fournit un fichier appelé « MakefileWorker.mk ». Il offre beaucoup de fonctionnalités qui simplifient la construction avec CppUTest. Le fichier se trouve dans le répertoire « build » du dépôt git. Pour ce tutoriel, nous allons supposer qu'il a été copié dans le répertoire ‘t/’. Il peut être utilisé comme suit :

# 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

Notez que CPPUTEST_HOME doit être défini à l'endroit où CppUTest a été installé. Si vous avez installé un paquet de distribution, cela se trouvera généralement sous /usr/local sur un système linux/mac. Si vous avez récupéré le dépôt par vous-même, c'est à l'endroit où se trouve ce dépôt.

Toutes ces options sont documentées dans MakefileWorker.mk.

MakefileWorker.mk ajoute également quelques cibles makefile, y compris les suivantes :

  1. all – compile les tests indiqués par le makefile

  2. clean – enlève tous les fichiers objets et gcov générés pour les tests

  3. realclean – enlève tous les fichiers objets ou gcov dans tout l'arborescence des répertoires

  4. flags – liste tous les drapeaux configurés utilisés pour compiler les tests

  5. debug – liste tous les fichiers sources, objets, dépendances et ‘choses à nettoyer’


Composant

Objectif

Fichiers / Drapeaux Clés

Notes

Makefile du projet

Constitue le code source principal

Makefile au niveau racine utilisant make -C

Compile src/ et délègue les tests à t/

Makefile des tests

Constitue et lie les tests avec CppUTest

t/Makefile faisant référence à MakefileWorker.mk

Gère la compilation des tests, l'édition de liens, et les drapeaux de bibliothèque

MakefileWorker.mk

Fournit une logique de construction réutilisable

Situé dans le répertoire CppUTest /build

Ajoute les cibles : all, clean, realclean, flags, debug

Intégration GCov

Permet la génération de rapports de couverture de code

CPPUTEST_USE_GCOV=Y

Produit des fichiers .gcov, des rapports HTML

Détection de fuites de mémoire

Détecte les fuites malloc/free

CPPUTEST_USE_MEM_LEAK_DETECTION

Activé par défaut ; peut être désactivé avec =N

Test Runner

Exécute les groupes de tests

CommandLineTestRunner

Point d'entrée principal requis pour l'exécution des tests

Pour les tests, les choses sont un peu plus compliquées car nous devons correctement charger et intégrer la bibliothèque CppUTest.

Le dépôt CppUTest fournit un fichier appelé « MakefileWorker.mk ». Il offre beaucoup de fonctionnalités qui simplifient la construction avec CppUTest. Le fichier se trouve dans le répertoire « build » du dépôt git. Pour ce tutoriel, nous allons supposer qu'il a été copié dans le répertoire ‘t/’. Il peut être utilisé comme suit :

# 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

Notez que CPPUTEST_HOME doit être défini à l'endroit où CppUTest a été installé. Si vous avez installé un paquet de distribution, cela se trouvera généralement sous /usr/local sur un système linux/mac. Si vous avez récupéré le dépôt par vous-même, c'est à l'endroit où se trouve ce dépôt.

Toutes ces options sont documentées dans MakefileWorker.mk.

MakefileWorker.mk ajoute également quelques cibles makefile, y compris les suivantes :

  1. all – compile les tests indiqués par le makefile

  2. clean – enlève tous les fichiers objets et gcov générés pour les tests

  3. realclean – enlève tous les fichiers objets ou gcov dans tout l'arborescence des répertoires

  4. flags – liste tous les drapeaux configurés utilisés pour compiler les tests

  5. debug – liste tous les fichiers sources, objets, dépendances et ‘choses à nettoyer’


Composant

Objectif

Fichiers / Drapeaux Clés

Notes

Makefile du projet

Constitue le code source principal

Makefile au niveau racine utilisant make -C

Compile src/ et délègue les tests à t/

Makefile des tests

Constitue et lie les tests avec CppUTest

t/Makefile faisant référence à MakefileWorker.mk

Gère la compilation des tests, l'édition de liens, et les drapeaux de bibliothèque

MakefileWorker.mk

Fournit une logique de construction réutilisable

Situé dans le répertoire CppUTest /build

Ajoute les cibles : all, clean, realclean, flags, debug

Intégration GCov

Permet la génération de rapports de couverture de code

CPPUTEST_USE_GCOV=Y

Produit des fichiers .gcov, des rapports HTML

Détection de fuites de mémoire

Détecte les fuites malloc/free

CPPUTEST_USE_MEM_LEAK_DETECTION

Activé par défaut ; peut être désactivé avec =N

Test Runner

Exécute les groupes de tests

CommandLineTestRunner

Point d'entrée principal requis pour l'exécution des tests

Pour les tests, les choses sont un peu plus compliquées car nous devons correctement charger et intégrer la bibliothèque CppUTest.

Le dépôt CppUTest fournit un fichier appelé « MakefileWorker.mk ». Il offre beaucoup de fonctionnalités qui simplifient la construction avec CppUTest. Le fichier se trouve dans le répertoire « build » du dépôt git. Pour ce tutoriel, nous allons supposer qu'il a été copié dans le répertoire ‘t/’. Il peut être utilisé comme suit :

# 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

Notez que CPPUTEST_HOME doit être défini à l'endroit où CppUTest a été installé. Si vous avez installé un paquet de distribution, cela se trouvera généralement sous /usr/local sur un système linux/mac. Si vous avez récupéré le dépôt par vous-même, c'est à l'endroit où se trouve ce dépôt.

Toutes ces options sont documentées dans MakefileWorker.mk.

MakefileWorker.mk ajoute également quelques cibles makefile, y compris les suivantes :

  1. all – compile les tests indiqués par le makefile

  2. clean – enlève tous les fichiers objets et gcov générés pour les tests

  3. realclean – enlève tous les fichiers objets ou gcov dans tout l'arborescence des répertoires

  4. flags – liste tous les drapeaux configurés utilisés pour compiler les tests

  5. debug – liste tous les fichiers sources, objets, dépendances et ‘choses à nettoyer’


Composant

Objectif

Fichiers / Drapeaux Clés

Notes

Makefile du projet

Constitue le code source principal

Makefile au niveau racine utilisant make -C

Compile src/ et délègue les tests à t/

Makefile des tests

Constitue et lie les tests avec CppUTest

t/Makefile faisant référence à MakefileWorker.mk

Gère la compilation des tests, l'édition de liens, et les drapeaux de bibliothèque

MakefileWorker.mk

Fournit une logique de construction réutilisable

Situé dans le répertoire CppUTest /build

Ajoute les cibles : all, clean, realclean, flags, debug

Intégration GCov

Permet la génération de rapports de couverture de code

CPPUTEST_USE_GCOV=Y

Produit des fichiers .gcov, des rapports HTML

Détection de fuites de mémoire

Détecte les fuites malloc/free

CPPUTEST_USE_MEM_LEAK_DETECTION

Activé par défaut ; peut être désactivé avec =N

Test Runner

Exécute les groupes de tests

CommandLineTestRunner

Point d'entrée principal requis pour l'exécution des tests

Code Coverage

Les tests unitaires ne seraient pas complets sans un rapport de couverture. L'outil de référence pour cela, pour les projets utilisant gcc, est gcov, disponible dans le cadre de la suite standard des utilitaires gcc. Cpputest s'intègre facilement avec gcov, tout ce que vous devez faire est d'ajouter cette ligne au makefile :

CPPUTEST_USE_GCOV=Y

Ensuite, nous devons nous assurer que le script filterGcov.sh de ce repo soit dans ‘/scripts/filterGcov.sh’ par rapport à l'endroit où vous avez défini ‘CPPUTEST_HOME’. Il doit également avoir des permissions d'exécution.

Dans le Makefile d'exemple, il serait déployé dans ‘/usr/local/scripts/filterGcov.sh’. Si vous exécutez CppUTest à partir d'un checkout de repo, tout devrait fonctionner sans modification.

Avec cela en place, vous pouvez simplement exécuter ‘make gcov’ et l’analyse sera générée pour vous. Dans notre cas, nous devrons ‘make -B’ pour reconstruire les fichiers objets avec gcov activé :

[]$ 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

Cela produira un certain nombre de fichiers dans un nouveau répertoire ‘gcov’. Ceux-ci sont :

  1. code.cpp.gcov – le fichier ‘gcov’ réel pour le code testé

  2. gcov_error.txt – un rapport d'erreur (dans notre cas, il devrait être vide)

  3. gcov_output.txt – la sortie réelle de la commande gcov qui a été exécutée

  4. gcov_report.txt – un résumé de la couverture pour chaque fichier testé

  5. gcov_report.txt.html – une version html du rapport gcov

Les tests unitaires ne seraient pas complets sans un rapport de couverture. L'outil de référence pour cela, pour les projets utilisant gcc, est gcov, disponible dans le cadre de la suite standard des utilitaires gcc. Cpputest s'intègre facilement avec gcov, tout ce que vous devez faire est d'ajouter cette ligne au makefile :

CPPUTEST_USE_GCOV=Y

Ensuite, nous devons nous assurer que le script filterGcov.sh de ce repo soit dans ‘/scripts/filterGcov.sh’ par rapport à l'endroit où vous avez défini ‘CPPUTEST_HOME’. Il doit également avoir des permissions d'exécution.

Dans le Makefile d'exemple, il serait déployé dans ‘/usr/local/scripts/filterGcov.sh’. Si vous exécutez CppUTest à partir d'un checkout de repo, tout devrait fonctionner sans modification.

Avec cela en place, vous pouvez simplement exécuter ‘make gcov’ et l’analyse sera générée pour vous. Dans notre cas, nous devrons ‘make -B’ pour reconstruire les fichiers objets avec gcov activé :

[]$ 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

Cela produira un certain nombre de fichiers dans un nouveau répertoire ‘gcov’. Ceux-ci sont :

  1. code.cpp.gcov – le fichier ‘gcov’ réel pour le code testé

  2. gcov_error.txt – un rapport d'erreur (dans notre cas, il devrait être vide)

  3. gcov_output.txt – la sortie réelle de la commande gcov qui a été exécutée

  4. gcov_report.txt – un résumé de la couverture pour chaque fichier testé

  5. gcov_report.txt.html – une version html du rapport gcov

Les tests unitaires ne seraient pas complets sans un rapport de couverture. L'outil de référence pour cela, pour les projets utilisant gcc, est gcov, disponible dans le cadre de la suite standard des utilitaires gcc. Cpputest s'intègre facilement avec gcov, tout ce que vous devez faire est d'ajouter cette ligne au makefile :

CPPUTEST_USE_GCOV=Y

Ensuite, nous devons nous assurer que le script filterGcov.sh de ce repo soit dans ‘/scripts/filterGcov.sh’ par rapport à l'endroit où vous avez défini ‘CPPUTEST_HOME’. Il doit également avoir des permissions d'exécution.

Dans le Makefile d'exemple, il serait déployé dans ‘/usr/local/scripts/filterGcov.sh’. Si vous exécutez CppUTest à partir d'un checkout de repo, tout devrait fonctionner sans modification.

Avec cela en place, vous pouvez simplement exécuter ‘make gcov’ et l’analyse sera générée pour vous. Dans notre cas, nous devrons ‘make -B’ pour reconstruire les fichiers objets avec gcov activé :

[]$ 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

Cela produira un certain nombre de fichiers dans un nouveau répertoire ‘gcov’. Ceux-ci sont :

  1. code.cpp.gcov – le fichier ‘gcov’ réel pour le code testé

  2. gcov_error.txt – un rapport d'erreur (dans notre cas, il devrait être vide)

  3. gcov_output.txt – la sortie réelle de la commande gcov qui a été exécutée

  4. gcov_report.txt – un résumé de la couverture pour chaque fichier testé

  5. gcov_report.txt.html – une version html du rapport gcov

Cpputest Détection de fuite de mémoire

Cpputest vous permet de détecter automatiquement les fuites de mémoire en redéfinissant la famille de fonctions standard « malloc/free » pour utiliser ses propres enveloppes à la place. Cela lui permet de détecter rapidement les fuites et de les signaler pour chaque exécution de test. Ceci est activé par défaut dans MakefileWorker.mk, donc il est déjà en marche avec les étapes décrites jusqu'à présent.

Pour illustrer, faisons une fuite de mémoire dans test_func() !

Revenons à code.c, nous ajoutons un malloc()  à la fonction, comme ceci :

int test_func() {
    malloc(1);
    return 1;
}

Maintenant, après recompilation, l'erreur suivante est produite :

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: <

Cela montre quel test a causé la fuite, où la fuite s'est produite dans le code source, et ce qui se trouvait dans la mémoire fuyante. Très utile!

Il y a quelques mises en garde avec cette fonctionnalité :

  1. Cpputest utilise des macros de préprocesseur pour redéfinir dynamiquement tous les appels aux fonctions de gestion de la mémoire standard. Cela signifie que cela ne fonctionnera que pour les appels dans le code source en test, car c'est ce qui est compilé avec les remplacements de CppUTest. Les fuites dans les bibliothèques liées ne seront pas détectées.

  2. Parfois, la mémoire qui est allouée pour toute la durée de vie du processus n'est pas destinée à être libérée. Cela peut générer de nombreuses erreurs spammantes si vous testez un module avec ce comportement. Pour désactiver la détection des fuites, vous pouvez faire ceci :

CPPUTEST_USE_MEM_LEAK_DETECTION=N

Cpputest vous permet de détecter automatiquement les fuites de mémoire en redéfinissant la famille de fonctions standard « malloc/free » pour utiliser ses propres enveloppes à la place. Cela lui permet de détecter rapidement les fuites et de les signaler pour chaque exécution de test. Ceci est activé par défaut dans MakefileWorker.mk, donc il est déjà en marche avec les étapes décrites jusqu'à présent.

Pour illustrer, faisons une fuite de mémoire dans test_func() !

Revenons à code.c, nous ajoutons un malloc()  à la fonction, comme ceci :

int test_func() {
    malloc(1);
    return 1;
}

Maintenant, après recompilation, l'erreur suivante est produite :

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: <

Cela montre quel test a causé la fuite, où la fuite s'est produite dans le code source, et ce qui se trouvait dans la mémoire fuyante. Très utile!

Il y a quelques mises en garde avec cette fonctionnalité :

  1. Cpputest utilise des macros de préprocesseur pour redéfinir dynamiquement tous les appels aux fonctions de gestion de la mémoire standard. Cela signifie que cela ne fonctionnera que pour les appels dans le code source en test, car c'est ce qui est compilé avec les remplacements de CppUTest. Les fuites dans les bibliothèques liées ne seront pas détectées.

  2. Parfois, la mémoire qui est allouée pour toute la durée de vie du processus n'est pas destinée à être libérée. Cela peut générer de nombreuses erreurs spammantes si vous testez un module avec ce comportement. Pour désactiver la détection des fuites, vous pouvez faire ceci :

CPPUTEST_USE_MEM_LEAK_DETECTION=N

Cpputest vous permet de détecter automatiquement les fuites de mémoire en redéfinissant la famille de fonctions standard « malloc/free » pour utiliser ses propres enveloppes à la place. Cela lui permet de détecter rapidement les fuites et de les signaler pour chaque exécution de test. Ceci est activé par défaut dans MakefileWorker.mk, donc il est déjà en marche avec les étapes décrites jusqu'à présent.

Pour illustrer, faisons une fuite de mémoire dans test_func() !

Revenons à code.c, nous ajoutons un malloc()  à la fonction, comme ceci :

int test_func() {
    malloc(1);
    return 1;
}

Maintenant, après recompilation, l'erreur suivante est produite :

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: <

Cela montre quel test a causé la fuite, où la fuite s'est produite dans le code source, et ce qui se trouvait dans la mémoire fuyante. Très utile!

Il y a quelques mises en garde avec cette fonctionnalité :

  1. Cpputest utilise des macros de préprocesseur pour redéfinir dynamiquement tous les appels aux fonctions de gestion de la mémoire standard. Cela signifie que cela ne fonctionnera que pour les appels dans le code source en test, car c'est ce qui est compilé avec les remplacements de CppUTest. Les fuites dans les bibliothèques liées ne seront pas détectées.

  2. Parfois, la mémoire qui est allouée pour toute la durée de vie du processus n'est pas destinée à être libérée. Cela peut générer de nombreuses erreurs spammantes si vous testez un module avec ce comportement. Pour désactiver la détection des fuites, vous pouvez faire ceci :

CPPUTEST_USE_MEM_LEAK_DETECTION=N

Autres nouvelles

Lire plus de cette catégorie

31 mars 2025

Créer des chatbots IA que les clients veulent réellement utiliser

15 août 2024

Comment personnaliser votre assistant IA pour améliorer le support client

AI

·

18 sept. 2024

Maximisez l'efficacité des agents clients avec 11 cas d'utilisation de l'IA

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

La plateforme native AI complète qui évolue avec votre business.

Contactez les ventes

Commencez gratuitement

© 2026 Bird

Contactez le Support

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

La plateforme native AI complète qui évolue avec votre business.

Contactez les ventes

Commencez gratuitement

© 2026 Bird

Contactez le Support

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

La plateforme native AI complète qui évolue avec votre business.

Contactez les ventes

Commencez gratuitement

© 2026 Bird

Contactez le Support