¿Qué es CppUTest y por qué usarlo?

Es un marco de pruebas robusto, de estilo xUnit, para C/C++ con una API limpia, macros de aserción integradas, detección de fugas y desarrollo activo, ideal para sistemas heredados o modernos.

¿Cómo se construyen pruebas sin configurar manualmente las opciones del compilador?

Utiliza MakefileWorker.mk de CppUTest, que maneja las banderas, el enlace y la ejecución de pruebas automáticamente.

¿Puede CppUTest detectar fugas de memoria automáticamente?

Sí. Sobrescribe malloc/free durante las compilaciones de prueba, informando: qué prueba tuvo fugas, dónde ocurrió, tamaño de la fuga y contenido de la memoria. Ejemplo de salida de fallo:

¿Cómo genero la cobertura de código?

Habilitar: CPPUTEST_USE_GCOV=Y Asegúrese de que filterGcov.sh esté disponible en $(CPPUTEST_HOME)/scripts/ . Ejecutar: make gcov Esto produce .gcov , texto resumen, y reportes de cobertura en HTML.

¿Qué más puede hacer CppUTest más allá de las pruebas básicas?

marco de pruebas simuladas sistema de complementos scripts de automatización de ayuda integración nativa de C macros de aserción extensas

¿Para quién es más adecuado CppUTest?

Equipos que trabajan con sistemas empotrados, plataformas C, servicios de C++, o cualquier entorno donde la fiabilidad y la seguridad de memoria deben ser validadas continuamente.

Introducción a CppUTest

Correo electrónico

14 may 2017

Puntos clave

- CppUTest es un marco de pruebas ligero, mantenido activamente, estilo xUnit para C/C++, con una capa de integración C que funciona sin problemas incluso en bases de código pesadas en C.
- Puede instalarlo a través de gestores de paquetes (distribuciones de Linux, Homebrew) o clonar el repositorio de GitHub.
- Una configuración mínima consiste en:
  - un directorio de producción src/,
  - un directorio de pruebas t/,
  - un runner de pruebas (CommandLineTestRunner), y
  - módulos de prueba utilizando bloques TEST_GROUP y TEST().
- CppUTest proporciona un ayudante MakefileWorker.mk que simplifica la construcción de pruebas, el enlace de bibliotecas y el manejo de flags.
- La detección de fugas de memoria está habilitada de forma predeterminada a través de sobrescrituras de malloc/free, capturando fugas dentro del código fuente probado.
- La cobertura de código a través de gcov se integra fácilmente habilitando CPPUTEST_USE_GCOV=Y, produciendo informes de cobertura completa y resúmenes en HTML.
- El marco incluye características avanzadas: mocks, plugins, scripts de ayuda e interoperabilidad directa con C, útiles para complejas bases de código empresariales.

Destacados de Q&A

¿Qué es CppUTest y por qué usarlo?
Es un marco de pruebas robusto, de estilo xUnit, para C/C++ con una API limpia, macros de aserción integradas, detección de fugas y desarrollo activo, ideal para sistemas heredados o modernos.
¿Cómo estructuras un proyecto básico usando 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)
¿Cómo se ejecutan todas las pruebas?
El test runner utiliza:
return CommandLineTestRunner::RunAllTests(ac, av);
return CommandLineTestRunner::RunAllTests(ac, av);
return CommandLineTestRunner::RunAllTests(ac, av);
¿Cómo se construyen pruebas sin configurar manualmente las opciones del compilador?
Utiliza MakefileWorker.mk de CppUTest, que maneja las banderas, el enlace y la ejecución de pruebas automáticamente.
¿Puede CppUTest detectar fugas de memoria automáticamente?
Sí. Sobrescribe malloc/free durante las compilaciones de prueba, informando:
- qué prueba tuvo fugas,
- dónde ocurrió,
- tamaño de la fuga y contenido de la memoria.
Ejemplo de salida de fallo:
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
¿Cómo genero la cobertura de código?
1. Habilitar: CPPUTEST_USE_GCOV=Y
2. Asegúrese de que filterGcov.sh esté disponible en $(CPPUTEST_HOME)/scripts/.
3. Ejecutar: make gcov
  Esto produce .gcov, texto resumen, y reportes de cobertura en HTML.
¿Qué más puede hacer CppUTest más allá de las pruebas básicas?
- marco de pruebas simuladas
- sistema de complementos
- scripts de automatización de ayuda
- integración nativa de C
- macros de aserción extensas
¿Para quién es más adecuado CppUTest?
Equipos que trabajan con sistemas empotrados, plataformas C, servicios de C++, o cualquier entorno donde la fiabilidad y la seguridad de memoria deben ser validadas continuamente.

En SparkPost, dedicamos mucho tiempo y esfuerzo a probar nuestro código. Nuestra plataforma está escrita en C, y recientemente investigué la integración con un marco de pruebas unitarias llamado “CppUTest”, que proporciona pruebas al estilo xUnit para C/C++. Este marco es sólido, rico en funciones y está en desarrollo activo, lo que lo convierte en una excelente opción. También proporciona una capa de integración en C que facilitó su uso con nuestro código en C de la plataforma, aunque la mayor parte del marco es C++. Este tutorial cubre cómo comenzar con CppUTest en tus propios proyectos.

¿Interesado en más?

Esto es solo la punta del iceberg cuando se trata de todas las características contenidas en esta herramienta. Además de lo básico discutido aquí, también tiene un marco de burla, una capa de integración directa con C y un marco de plugins, por nombrar algunos de los más importantes. El repositorio también contiene todo un directorio de scripts auxiliares que pueden ayudar a automatizar algunas de las partes rutinarias de trabajar con el marco.

¡Espero que la información aquí te ayude a mejorar la calidad de tu código C/C++ con esta gran herramienta!

Descargando CppUTest

La página del proyecto CppUTest está disponible en el sitio web oficial, y el repositorio está en github. También está incluido en los repositorios de gestión de paquetes para muchas distribuciones de Linux, así como en homebrew en Mac OS. Los ejemplos que siguen fueron ejecutados en Mac OS X, pero se derivan de código escrito para Red Hat, el sistema operativo en el que nuestra plataforma se ejecuta.

Los conceptos básicos están bien documentados en la página de inicio de CppUTest. Vamos a pasar por eso rápidamente y llegar a algunas de las características más interesantes.

Laying the Foundation

Lo primero es lo primero, ¡vamos a escribir algo de código!

Nuestro proyecto de prueba tendrá un archivo ‘main’ e incluirá una biblioteca de utilidades llamada ‘code’. La biblioteca proporcionará una función simple que devuelve 1 (por ahora). Los archivos estarán dispuestos de esta manera:

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

Comencemos escribiendo los archivos de 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

Ahora, hagamos las pruebas, que vivirán en el directorio t/. Lo primero que hay que hacer es configurar un corredor de pruebas que ejecutará nuestros archivos de prueba. Esta también es la función ‘main’ que se ejecutará una vez que todo esto esté compilado:

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

Ahora podemos escribir nuestro primer módulo de prueba:

// t/test.cpp
#include "CppUTest/TestHarness.h"
#include "code.h"
TEST_GROUP(AwesomeExamples)
{
};
TEST(AwesomeExamples, FirstExample)
{
    int x = test_func();
    CHECK_EQUAL(1, x);
}

Después, necesitamos escribir makefiles. Necesitaremos dos: uno para los archivos del proyecto bajo src/, y otro para las pruebas.

Lo primero es lo primero, ¡vamos a escribir algo de código!

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

Comencemos escribiendo los archivos de 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);
}

Ahora podemos escribir nuestro primer módulo de prueba:

// t/test.cpp
#include "CppUTest/TestHarness.h"
#include "code.h"
TEST_GROUP(AwesomeExamples)
{
};
TEST(AwesomeExamples, FirstExample)
{
    int x = test_func();
    CHECK_EQUAL(1, x);
}

Después, necesitamos escribir makefiles. Necesitaremos dos: uno para los archivos del proyecto bajo src/, y otro para las pruebas.

Lo primero es lo primero, ¡vamos a escribir algo de código!

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

Comencemos escribiendo los archivos de 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);
}

Ahora podemos escribir nuestro primer módulo de prueba:

// t/test.cpp
#include "CppUTest/TestHarness.h"
#include "code.h"
TEST_GROUP(AwesomeExamples)
{
};
TEST(AwesomeExamples, FirstExample)
{
    int x = test_func();
    CHECK_EQUAL(1, x);
}

Después, necesitamos escribir makefiles. Necesitaremos dos: uno para los archivos del proyecto bajo src/, y otro para las pruebas.

Proyecto Makefile

El makefile del proyecto estará al mismo nivel que los directorios ‘src’ y ‘t’ en la raíz del proyecto. Debería verse así:

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

Note que este utiliza ‘make -C’ para los objetivos de prueba – lo que significa que llamará a ‘make’ de nuevo usando el makefile en el directorio de prueba.

En este punto podemos compilar el código ‘src’ con el makefile y ver que funciona:

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

El makefile del proyecto estará al mismo nivel que los directorios ‘src’ y ‘t’ en la raíz del proyecto. Debería verse así:

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

Note que este utiliza ‘make -C’ para los objetivos de prueba – lo que significa que llamará a ‘make’ de nuevo usando el makefile en el directorio de prueba.

En este punto podemos compilar el código ‘src’ con el makefile y ver que funciona:

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

El makefile del proyecto estará al mismo nivel que los directorios ‘src’ y ‘t’ en la raíz del proyecto. Debería verse así:

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

Note que este utiliza ‘make -C’ para los objetivos de prueba – lo que significa que llamará a ‘make’ de nuevo usando el makefile en el directorio de prueba.

En este punto podemos compilar el código ‘src’ con el makefile y ver que funciona:

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

Para las pruebas, las cosas son un poco más complicadas ya que necesitamos cargar e integrarnos adecuadamente con la librería CppUTest.

El repositorio de CppUTest proporciona un archivo llamado “MakefileWorker.mk”. Proporciona mucha funcionalidad que hace que la construcción con CppUTest sea simple. El archivo se encuentra en el directorio “build” en el repositorio de git. Para este tutorial vamos a suponer que se ha copiado al directorio ‘t/’. Se puede usar de la siguiente manera:

# 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

Observa que CPPUTEST_HOME debe establecerse donde sea que CppUTest haya sido instalado. Si has instalado un paquete de distro, típicamente estará bajo /usr/local en un sistema linux/mac. Si has descargado el repositorio por tu cuenta, es donde sea que lo hayas descargado.

Estas opciones están documentadas en MakefileWorker.mk.

MakefileWorker.mk también añade algunos objetivos de makefile, incluyendo los siguientes:

all – construye las pruebas indicadas por el makefile
clean – elimina todos los archivos objeto y gcov generados para las pruebas
realclean – elimina cualquier archivo objeto o gcov en todo el árbol de directorios
flags – lista todas las banderas configuradas usadas para compilar las pruebas
debug – lista todos los archivos fuente, objetos, dependencias, y ‘cosas a limpiar’

Componente	Propósito	Archivos Clave / Banderas	Notas
Project Makefile	Construye el código fuente principal	Makefile de nivel raíz usando make `-C`	Compila `src/` y delega pruebas a `t/`
Tests Makefile	Construye y enlaza pruebas con CppUTest	`t/Makefile` referenciando `MakefileWorker.mk`	Maneja la compilación de pruebas, el enlace y las banderas de librería
MakefileWorker.mk	Proporciona lógica de construcción reutilizable	Ubicado en el dir `/build` de CppUTest	Añade objetivos: `all`, `clean`, `realclean`, `flags`, `debug`
Integración GCov	Habilita informes de cobertura de código	`CPPUTEST_USE_GCOV=Y`	Produce archivos `.gcov`, informes HTML
Detección de Fugas de Memoria	Detecta fugas de malloc/free	`CPPUTEST_USE_MEM_LEAK_DETECTION`	Activado por defecto; puede desactivarse con `=N`
Ejecutor de Pruebas	Ejecuta grupos de pruebas	`CommandLineTestRunner`	Punto de entrada principal requerido para ejecutar pruebas

Para las pruebas, las cosas son un poco más complicadas ya que necesitamos cargar e integrarnos adecuadamente con la librería 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

Estas opciones están documentadas en MakefileWorker.mk.

MakefileWorker.mk también añade algunos objetivos de makefile, incluyendo los siguientes:

all – construye las pruebas indicadas por el makefile
clean – elimina todos los archivos objeto y gcov generados para las pruebas
realclean – elimina cualquier archivo objeto o gcov en todo el árbol de directorios
flags – lista todas las banderas configuradas usadas para compilar las pruebas
debug – lista todos los archivos fuente, objetos, dependencias, y ‘cosas a limpiar’

Componente	Propósito	Archivos Clave / Banderas	Notas
Project Makefile	Construye el código fuente principal	Makefile de nivel raíz usando make `-C`	Compila `src/` y delega pruebas a `t/`
Tests Makefile	Construye y enlaza pruebas con CppUTest	`t/Makefile` referenciando `MakefileWorker.mk`	Maneja la compilación de pruebas, el enlace y las banderas de librería
MakefileWorker.mk	Proporciona lógica de construcción reutilizable	Ubicado en el dir `/build` de CppUTest	Añade objetivos: `all`, `clean`, `realclean`, `flags`, `debug`
Integración GCov	Habilita informes de cobertura de código	`CPPUTEST_USE_GCOV=Y`	Produce archivos `.gcov`, informes HTML
Detección de Fugas de Memoria	Detecta fugas de malloc/free	`CPPUTEST_USE_MEM_LEAK_DETECTION`	Activado por defecto; puede desactivarse con `=N`
Ejecutor de Pruebas	Ejecuta grupos de pruebas	`CommandLineTestRunner`	Punto de entrada principal requerido para ejecutar pruebas

Para las pruebas, las cosas son un poco más complicadas ya que necesitamos cargar e integrarnos adecuadamente con la librería 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

Estas opciones están documentadas en MakefileWorker.mk.

MakefileWorker.mk también añade algunos objetivos de makefile, incluyendo los siguientes:

all – construye las pruebas indicadas por el makefile
clean – elimina todos los archivos objeto y gcov generados para las pruebas
realclean – elimina cualquier archivo objeto o gcov en todo el árbol de directorios
flags – lista todas las banderas configuradas usadas para compilar las pruebas
debug – lista todos los archivos fuente, objetos, dependencias, y ‘cosas a limpiar’

Componente	Propósito	Archivos Clave / Banderas	Notas
Project Makefile	Construye el código fuente principal	Makefile de nivel raíz usando make `-C`	Compila `src/` y delega pruebas a `t/`
Tests Makefile	Construye y enlaza pruebas con CppUTest	`t/Makefile` referenciando `MakefileWorker.mk`	Maneja la compilación de pruebas, el enlace y las banderas de librería
MakefileWorker.mk	Proporciona lógica de construcción reutilizable	Ubicado en el dir `/build` de CppUTest	Añade objetivos: `all`, `clean`, `realclean`, `flags`, `debug`
Integración GCov	Habilita informes de cobertura de código	`CPPUTEST_USE_GCOV=Y`	Produce archivos `.gcov`, informes HTML
Detección de Fugas de Memoria	Detecta fugas de malloc/free	`CPPUTEST_USE_MEM_LEAK_DETECTION`	Activado por defecto; puede desactivarse con `=N`
Ejecutor de Pruebas	Ejecuta grupos de pruebas	`CommandLineTestRunner`	Punto de entrada principal requerido para ejecutar pruebas

Code Coverage

Las pruebas unitarias no estarían completas sin un informe de cobertura. La herramienta predilecta para esto en proyectos que usan gcc es gcov, disponible como parte del conjunto estándar de utilidades de gcc. Cpputest se integra fácilmente con gcov, todo lo que necesitas hacer es agregar esta línea al makefile:

CPPUTEST_USE_GCOV=Y

A continuación, necesitamos asegurarnos de que el script filterGcov.sh del este repositorio esté en ‘/scripts/filterGcov.sh’ relativo a donde sea que hayas establecido ‘CPPUTEST_HOME’. También necesita tener permisos de ejecución.

En el Makefile de ejemplo, se desplegaría en ‘/usr/local/scripts/filterGcov.sh’. Si estás ejecutando CppUTest desde una clonación del repositorio, todo debería funcionar sin modificaciones.

Con eso en su lugar, simplemente puedes ejecutar ‘make gcov’ y el análisis se generará para ti. En nuestro caso, necesitaremos usar ‘make -B’ para reconstruir los archivos objeto habilitados con gcov:

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

Esto generará varios archivos en un nuevo directorio ‘gcov’. Estos son:

code.cpp.gcov – el archivo ‘gcov’ real del código que se está probando
gcov_error.txt – un informe de errores (en nuestro caso, debería estar vacío)
gcov_output.txt – la salida real del comando gcov que se ejecutó
gcov_report.txt – un resumen de la cobertura de cada archivo probado
gcov_report.txt.html – una versión html de gcov_report

CPPUTEST_USE_GCOV=Y

En el Makefile de ejemplo, se desplegaría en ‘/usr/local/scripts/filterGcov.sh’. Si estás ejecutando CppUTest desde una clonación del repositorio, todo debería funcionar sin modificaciones.

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

Esto generará varios archivos en un nuevo directorio ‘gcov’. Estos son:

code.cpp.gcov – el archivo ‘gcov’ real del código que se está probando
gcov_error.txt – un informe de errores (en nuestro caso, debería estar vacío)
gcov_output.txt – la salida real del comando gcov que se ejecutó
gcov_report.txt – un resumen de la cobertura de cada archivo probado
gcov_report.txt.html – una versión html de gcov_report

CPPUTEST_USE_GCOV=Y

En el Makefile de ejemplo, se desplegaría en ‘/usr/local/scripts/filterGcov.sh’. Si estás ejecutando CppUTest desde una clonación del repositorio, todo debería funcionar sin modificaciones.

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

Esto generará varios archivos en un nuevo directorio ‘gcov’. Estos son:

code.cpp.gcov – el archivo ‘gcov’ real del código que se está probando
gcov_error.txt – un informe de errores (en nuestro caso, debería estar vacío)
gcov_output.txt – la salida real del comando gcov que se ejecutó
gcov_report.txt – un resumen de la cobertura de cada archivo probado
gcov_report.txt.html – una versión html de gcov_report

Cpputest Memory Leak Detection

Cpputest te permite detectar automáticamente memoria filtrada redefiniendo la familia estándar de funciones "malloc/free" para usar sus propios envoltorios en su lugar. Esto le permite detectar rápidamente las fugas y reportarlas para cada ejecución de prueba. Esto está habilitado por defecto en MakefileWorker.mk, por lo que ya está activado con los pasos descritos hasta ahora.

Para ilustrar, ¡vamos a filtrar algo de memoria en test_func() !

Volviendo a code.c, añadimos un malloc() a la función, de la siguiente manera:

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

Ahora, después de recompilar, se produce el siguiente error:

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

Esto muestra qué prueba causó la fuga, dónde ocurrió la fuga en el código fuente y qué había en la memoria filtrada. ¡Muy útil!

Hay un par de advertencias con esta característica:

Cpputest está usando macros de preprocesador para redefinir dinámicamente todas las llamadas a las funciones estándar de gestión de memoria. Eso significa que solo funcionará para las llamadas en el código fuente bajo prueba, ya que eso es lo que se compila con las modificaciones de CppUTest. Las filtraciones en las bibliotecas vinculadas no serán detectadas.
A veces, la memoria que se asigna para toda la vida del proceso no está destinada a ser liberada. Esto puede crear muchos errores molestos si estás probando un módulo con este comportamiento. Para deshabilitar la detección de fugas, puedes hacer esto:

CPPUTEST_USE_MEM_LEAK_DETECTION=N

Para ilustrar, ¡vamos a filtrar algo de memoria en test_func() !

Volviendo a code.c, añadimos un malloc() a la función, de la siguiente manera:

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

Ahora, después de recompilar, se produce el siguiente error:

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

Esto muestra qué prueba causó la fuga, dónde ocurrió la fuga en el código fuente y qué había en la memoria filtrada. ¡Muy útil!

Hay un par de advertencias con esta característica:

Cpputest está usando macros de preprocesador para redefinir dinámicamente todas las llamadas a las funciones estándar de gestión de memoria. Eso significa que solo funcionará para las llamadas en el código fuente bajo prueba, ya que eso es lo que se compila con las modificaciones de CppUTest. Las filtraciones en las bibliotecas vinculadas no serán detectadas.
A veces, la memoria que se asigna para toda la vida del proceso no está destinada a ser liberada. Esto puede crear muchos errores molestos si estás probando un módulo con este comportamiento. Para deshabilitar la detección de fugas, puedes hacer esto:

CPPUTEST_USE_MEM_LEAK_DETECTION=N

Para ilustrar, ¡vamos a filtrar algo de memoria en test_func() !

Volviendo a code.c, añadimos un malloc() a la función, de la siguiente manera:

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

Ahora, después de recompilar, se produce el siguiente error:

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

Esto muestra qué prueba causó la fuga, dónde ocurrió la fuga en el código fuente y qué había en la memoria filtrada. ¡Muy útil!

Hay un par de advertencias con esta característica:

Cpputest está usando macros de preprocesador para redefinir dinámicamente todas las llamadas a las funciones estándar de gestión de memoria. Eso significa que solo funcionará para las llamadas en el código fuente bajo prueba, ya que eso es lo que se compila con las modificaciones de CppUTest. Las filtraciones en las bibliotecas vinculadas no serán detectadas.
A veces, la memoria que se asigna para toda la vida del proceso no está destinada a ser liberada. Esto puede crear muchos errores molestos si estás probando un módulo con este comportamiento. Para deshabilitar la detección de fugas, puedes hacer esto:

CPPUTEST_USE_MEM_LEAK_DETECTION=N

Otras noticias

Leer más de esta categoría

31 mar 2025

Creando AI Chatbots que los Clientes Realmente Quieren Usar

15 ago 2024

Cómo personalizar tu asistente de IA para mejorar el soporte al cliente

18 sept 2024

Maximiza la eficiencia del agente de atención al cliente con 11 casos de uso de IA

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

La plataforma completa AI-native que escala con tu negocio.

Contactar con ventas

Empieza gratis

Contactar Soporte

La plataforma completa AI-native que escala con tu negocio.

Contactar con ventas

Empieza gratis

Contactar Soporte

La plataforma completa AI-native que escala con tu negocio.

Contactar con ventas

Empieza gratis

Contactar Soporte

Puntos clave

Destacados de Q&A

¿Qué es CppUTest y por qué usarlo?

¿Cómo estructuras un proyecto básico usando CppUTest?

¿Cómo se ejecutan todas las pruebas?

¿Cómo se construyen pruebas sin configurar manualmente las opciones del compilador?

¿Puede CppUTest detectar fugas de memoria automáticamente?

¿Cómo genero la cobertura de código?

¿Qué más puede hacer CppUTest más allá de las pruebas básicas?

¿Para quién es más adecuado CppUTest?

¿Interesado en más?

Descargando CppUTest

Laying the Foundation

Proyecto Makefile

Tests Makefile

Code Coverage

Cpputest Memory Leak Detection

Creando AI Chatbots que los Clientes Realmente Quieren Usar

Cómo personalizar tu asistente de IA para mejorar el soporte al cliente

Maximiza la eficiencia del agente de atención al cliente con 11 casos de uso de IA

Creando AI Chatbots que los Clientes Realmente Quieren Usar

Cómo personalizar tu asistente de IA para mejorar el soporte al cliente

Maximiza la eficiencia del agente de atención al cliente con 11 casos de uso de IA

Creando AI Chatbots que los Clientes Realmente Quieren Usar

Cómo personalizar tu asistente de IA para mejorar el soporte al cliente

Maximiza la eficiencia del agente de atención al cliente con 11 casos de uso de IA

Creando AI Chatbots que los Clientes Realmente Quieren Usar

Cómo personalizar tu asistente de IA para mejorar el soporte al cliente

Maximiza la eficiencia del agente de atención al cliente con 11 casos de uso de IA

Creando AI Chatbots que los Clientes Realmente Quieren Usar

Cómo personalizar tu asistente de IA para mejorar el soporte al cliente

Maximiza la eficiencia del agente de atención al cliente con 11 casos de uso de IA

La plataforma completa AI-native que escala con tu negocio.

Product

Soluciones

Recursos

Compañía

Próximamente

Social

Product

Soluciones

Recursos

Compañía

Próximamente

Social