Código de prueba de unidad C [cerrado]

Trabajé en un sistema embebido este verano escrito en línea C. Era un proyecto existente que la compañía para la que trabajo había asumido. Me he acostumbrado bastante a escribir pruebas unitarias en Java usando JUnit, pero no sabía cuál era la mejor manera de escribir pruebas unitarias para el código existente (que necesitaba una refactorización), así como el nuevo código agregado al sistema.

¿Hay algún proyecto que haga que las pruebas unitarias de código C simple sean tan fáciles como las pruebas unitarias de código Java con JUnit? Cualquier idea que se aplique específicamente al desarrollo integrado (compilación cruzada con la plataforma arm-linux) sería muy apreciada.

Un marco de prueba de unidad en C es Check ; Aquí se puede encontrar una lista de marcos de pruebas unitarias en C y se reproduce a continuación. Dependiendo de cuántas funciones de biblioteca estándar tenga su tiempo de ejecución, puede o no usar una de ellas.

AceUnit

AceUnit (Advanced C and Embedded Unit) se presenta como un marco de prueba de unidad de código C cómodo. Intenta imitar JUnit 4.xy incluye capacidades de reflexión. AceUnit se puede usar en entornos de restricción de recursos, por ejemplo, desarrollo de software integrado, y lo que es más importante, funciona bien en entornos en los que no puede incluir un solo archivo de encabezado estándar y no puede invocar una única función C estándar de las bibliotecas ANSI / ISO C. También tiene un puerto de Windows. No utiliza horquillas para atrapar señales, aunque los autores han expresado interés en agregar dicha característica. Vea la página de inicio de AceUnit .

GNU Autounit

En la misma línea que Check, incluida la bifurcación para ejecutar pruebas unitarias en un espacio de direcciones separado (de hecho, el autor original de Check tomó prestada la idea de GNU Autounit). GNU Autounit usa GLib ampliamente, lo que significa que los enlaces y demás necesitan opciones especiales, pero esto puede no ser un gran problema para usted, especialmente si ya está usando GTK o GLib. Vea la página de inicio de GNU Autounit .

cUnit

También usa GLib, pero no se bifurca para proteger el espacio de direcciones de las pruebas unitarias.

UNIDAD

Estándar C, con planes para una implementación de GUI Win32. Actualmente no bifurca ni protege el espacio de direcciones de las pruebas unitarias. En desarrollo temprano. Vea la página de inicio de CUnit .

CuTest

Un marco simple con solo un archivo .c y un archivo .h que coloca en su árbol de origen. Ver la página de inicio de CuTest .

CppUnit

El principal marco de pruebas unitarias para C ++; También puede usarlo para probar el código C. Es estable, desarrollado activamente y tiene una interfaz GUI. Las razones principales para no usar CppUnit para C son primero que es bastante grande, y segundo, debes escribir tus pruebas en C ++, lo que significa que necesitas un compilador de C ++. Si esto no suena como una preocupación, definitivamente vale la pena considerarlo, junto con otros marcos de prueba de unidades C ++. Vea la página de inicio de CppUnit .

unidad

embUnit (Embedded Unit) es otro marco de prueba de unidad para sistemas embebidos. Este parece ser reemplazado por AceUnit. Página de inicio de la Unidad Embebida .

MinUnit

¡Un conjunto mínimo de macros y listo! El punto es mostrar cuán fácil es probar unitariamente su código. Vea la página de inicio de MinUnit .

CUnit para el Sr. Ando

Una implementación de CUnit que es bastante nueva, y aparentemente todavía está en desarrollo temprano. Vea la página web de CUnit para el Sr. Ando .

Esta lista se actualizó por última vez en marzo de 2008.

Más marcos:

CMocka

CMocka es un marco de prueba para C con soporte para objetos simulados. Es fácil de usar y configurar.

Vea la página de inicio de CMocka .

Criterio

Criterion es un marco de prueba de unidades C multiplataforma que admite el registro automático de pruebas, pruebas parametrizadas, teorías y que puede generar en múltiples formatos, incluidos TAP y JUnit XML. Cada prueba se ejecuta en su propio proceso, por lo que las señales y los bloqueos se pueden informar o probar si es necesario.

Consulte la página de inicio de Criterion para obtener más información.

HWUT

HWUT es una herramienta de prueba de unidad general con gran soporte para C. Puede ayudar a crear Makefiles, generar casos de prueba masivos codificados en 'tablas de iteración' mínimas, caminar a lo largo de máquinas de estado, generar C-stubs y más. El enfoque general es bastante único: los veredictos se basan en 'stdout bueno / stdout malo'. La función de comparación, sin embargo, es flexible. Por lo tanto, se puede usar cualquier tipo de secuencia de comandos para la comprobación. Se puede aplicar a cualquier idioma que pueda producir una salida estándar.

Vea la página de inicio de HWUT .

CGreen

Un marco de prueba y burla de unidades moderno, portátil y en varios idiomas para C y C ++. Ofrece una notación BDD opcional, una biblioteca de imitación, la capacidad de ejecutarla en un solo proceso (para facilitar la depuración). Un corredor de prueba que descubre automáticamente las funciones de prueba está disponible. Pero puedes crear tu propia programación.

Todas esas características (y más) se explican en el manual de CGreen .

Wikipedia proporciona una lista detallada de los marcos de prueba de unidad C en la Lista de marcos de prueba de unidad: C

Personalmente me gusta el marco de prueba de Google .

La verdadera dificultad para probar el código C es romper las dependencias de los módulos externos para que pueda aislar el código en unidades. Esto puede ser especialmente problemático cuando intenta obtener pruebas de código heredado. En este caso, a menudo me encuentro usando el enlazador para usar funciones de código auxiliar en las pruebas.

A esto se refiere la gente cuando habla de " costuras ". En C, su única opción es usar el preprocesador o el enlazador para burlarse de sus dependencias.

Un conjunto de pruebas típico en uno de mis proyectos en C podría verse así:

#include "myimplementationfile.c"
#include <gtest/gtest.h>

// Mock out external dependency on mylogger.o
void Logger_log(...){}

TEST(FactorialTest, Zero) {
    EXPECT_EQ(1, Factorial(0));
}

Tenga en cuenta que en realidad está incluyendo el archivo C y no el archivo de encabezado . Esto brinda la ventaja de acceso a todos los miembros de datos estáticos. Aquí me burlo de mi registrador (que podría estar en logger.o y le doy una implementación vacía. Esto significa que el archivo de prueba se compila y enlaza independientemente del resto de la base de código y se ejecuta de forma aislada.

En cuanto a la compilación cruzada del código, para que esto funcione, necesita buenas instalaciones en el destino. He hecho esto con googletest cross compilado a Linux en una arquitectura PowerPC. Esto tiene sentido porque allí tiene un shell completo y un sistema operativo para recopilar sus resultados. Para entornos menos ricos (que clasifico como cualquier cosa sin un sistema operativo completo), solo debe compilar y ejecutar en el host. Debería hacer esto de todos modos para poder ejecutar las pruebas automáticamente como parte de la compilación.

Encuentro que probar el código C ++ generalmente es mucho más fácil debido al hecho de que el código OO en general está mucho menos acoplado que el procedimiento (por supuesto, esto depende mucho del estilo de codificación). También en C ++ puede usar trucos como la inyección de dependencia y la anulación de métodos para obtener uniones en el código que de otro modo está encapsulado.

Michael Feathers tiene un excelente libro sobre pruebas de código heredado . En un capítulo, él cubre técnicas para lidiar con código que no es OO, lo cual recomiendo encarecidamente.

Editar : he escrito una publicación de blog sobre el código de procedimiento de prueba de unidad, con fuente disponible en GitHub .

Editar : Hay un nuevo libro que sale de los Programadores Pragmáticos que aborda específicamente el código C de prueba de unidad que recomiendo encarecidamente .

Minunit es un marco de prueba de unidad increíblemente simple. Lo estoy usando para probar el código del microcontrolador c para avr.

Actualmente estoy usando el marco de prueba de la unidad CuTest:

http://cutest.sourceforge.net/

Es ideal para sistemas integrados, ya que es muy ligero y simple. No tuve problemas para que funcione en la plataforma de destino, así como en el escritorio. Además de escribir las pruebas unitarias, todo lo que se requiere es:

• un archivo de encabezado incluido donde quiera que llame a las rutinas CuTest
• un solo archivo 'C' adicional para ser compilado / vinculado a la imagen
• se agrega un código simple a main para configurar y llamar a las pruebas unitarias; solo tengo esto en una función main () especial que se compila si UNITTEST se define durante la compilación.

El sistema debe admitir un montón y alguna funcionalidad estándar (que no todos los sistemas integrados tienen). Pero el código es lo suficientemente simple como para que probablemente pueda trabajar en alternativas a esos requisitos si su plataforma no los tiene.

Con un uso juicioso de los bloques externos "C" {}, también admite probar C ++ perfectamente.

Digo casi lo mismo que ratkok, pero si tienes un giro incrustado en las pruebas unitarias, entonces ...

Unidad : marco altamente recomendado para pruebas unitarias de código C.

Los ejemplos en el libro que se menciona en este hilo TDD para C incrustado se escriben usando Unity (y CppUTest).

También es posible que desee echar un vistazo a libtap , un marco de prueba C que genera el Protocolo Test Anything (TAP) y, por lo tanto, se integra bien con una variedad de herramientas que salen a la luz para esta tecnología. Se usa principalmente en el mundo del lenguaje dinámico, pero es fácil de usar y se está volviendo muy popular.

Un ejemplo:

#include <tap.h>

int main () {
    plan(5);

    ok(3 == 3);
    is("fnord", "eek", "two different strings not that way?");
    ok(3 <= 8732, "%d <= %d", 3, 8732);
    like("fnord", "f(yes|no)r*[a-f]$");
    cmp_ok(3, ">=", 10);

    done_testing();
}

Hay un marco de prueba de unidad elegante para C con soporte para objetos simulados llamado cmocka . Solo requiere la biblioteca C estándar, funciona en una variedad de plataformas informáticas (incluidas las integradas) y con diferentes compiladores.

También tiene soporte para diferentes formatos de salida de mensajes como Subunit, Test Anything Protocol e informes jUnit XML.

cmocka ha sido creado para funcionar también en plataformas integradas y también tiene soporte para Windows.

Una prueba simple se ve así:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
    (void) state; /* unused */
}

int main(void) {
    const struct CMUnitTest tests[] = {
        cmocka_unit_test(null_test_success),
    };
    return cmocka_run_group_tests(tests, NULL, NULL);
}

los API está completamente documentada y varios ejemplos son parte del código fuente.

Para comenzar con cmocka, debe leer el artículo en LWN.net: Pruebas unitarias con objetos simulados en C

cmocka 1.0 se lanzó en febrero de 2015.

No llegué lejos probando una aplicación C heredada antes de comenzar a buscar una forma de simular funciones. Necesitaba mucho simulacros para aislar el archivo C que quiero probar de los demás. Intenté con cmock y creo que lo adoptaré.

Cmock escanea los archivos de encabezado y genera funciones simuladas basadas en los prototipos que encuentra. Los simulacros te permitirán probar un archivo C en perfecto aislamiento. Todo lo que tendrá que hacer es vincular su archivo de prueba con simulacros en lugar de sus archivos de objetos reales.

Otra ventaja de cmock es que validará los parámetros pasados ​​a las funciones simuladas, y le permitirá especificar qué valor de retorno deben proporcionar los simulacros. Esto es muy útil para probar diferentes flujos de ejecución en sus funciones.

Las pruebas consisten en las funciones típicas testA (), testB () en las que construye expectativas, llama a funciones para probar y verifica afirmaciones.

El último paso es generar un corredor para sus pruebas con unidad. Cmock está vinculado al marco de prueba de la unidad. La unidad es tan fácil de aprender como cualquier otro marco de prueba de unidad.

Vale la pena intentarlo y es bastante fácil de entender:

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

Actualización 1

Otro marco que estoy investigando es Cmockery.

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

Es un marco C puro que admite pruebas y burlas de unidades. No depende de ruby ​​(al contrario de Cmock) y tiene muy poca dependencia de libs externas.

Se requiere un poco más de trabajo manual para configurar simulacros porque no genera código. Eso no representa mucho trabajo para un proyecto existente ya que los prototipos no cambiarán mucho: una vez que tenga sus simulacros, no necesitará cambiarlos por un tiempo (este es mi caso). La escritura adicional proporciona un control completo de los simulacros. Si hay algo que no le gusta, simplemente cambie su simulación.

No es necesario un corredor de prueba especial. Solo necesita crear una matriz de pruebas y pasarla a una función run_tests. Un poco más de trabajo manual aquí también, pero definitivamente me gusta la idea de un marco autónomo autónomo.

Además, contiene algunos trucos ingeniosos de C que no conocía.

Cmockery en general necesita un poco más de comprensión de las simulaciones para comenzar. Los ejemplos deberían ayudarte a superar esto. Parece que puede hacer el trabajo con una mecánica más simple.

Como novato en C, encontré las diapositivas llamadas Desarrollo impulsado por pruebas en C muy útiles. Básicamente, utiliza el estándar assert()junto con &&para entregar un mensaje, sin ninguna dependencia externa. Si alguien está acostumbrado a un marco de prueba de pila completa, esto probablemente no funcionará :)

Escribimos CHEAT (alojado en GitHub ) para facilitar su uso y portabilidad.

No tiene dependencias y no requiere instalación o configuración. Solo se necesita un archivo de encabezado y un caso de prueba.

#include <cheat.h>

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

Las pruebas se compilan en un ejecutable que se encarga de ejecutar las pruebas e informar sus resultados.

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

Tiene bonitos colores también.

Hay CUnit

Y Embedded Unit es un marco de prueba de unidad para Embedded C System. Su diseño se copió de JUnit y CUnit y más, y luego se adaptó un poco para Embedded C System. Embedded Unit no requiere std C libs. Todos los objetos se asignan al área constante.

Y Tessy automatiza las pruebas unitarias de software embebido.

No uso un marco, solo uso el soporte de objetivo "check" de herramientas automáticas. Implemente un "principal" y use aserción (es).

Mi directorio de prueba Makefile.am (s) se ve así:

check_PROGRAMS = test_oe_amqp

test_oe_amqp_SOURCES = test_oe_amqp.c
test_oe_amqp_LDADD = -L$(top_builddir)/components/common -loecommon
test_oe_amqp_CFLAGS = -I$(top_srcdir)/components/common -static

TESTS = test_oe_amqp

El libro de Michael Feather "Trabajando eficazmente con código heredado" presenta muchas técnicas específicas para las pruebas unitarias durante el desarrollo de C.

Existen técnicas relacionadas con la inyección de dependencia que son específicas de C y que no he visto en ningún otro lado.

CppUTest : marco altamente recomendado para pruebas unitarias de código C.

Los ejemplos en el libro que se menciona en este hilo TDD para C incrustado se escriben usando CppUTest.

Utilizo CxxTest para un entorno c / c ++ incrustado (principalmente C ++).

Prefiero CxxTest porque tiene un script perl / python para construir el corredor de prueba. Después de una pequeña pendiente para configurarlo (aún más pequeño ya que no tiene que escribir el corredor de prueba), es bastante fácil de usar (incluye muestras y documentación útil). La mayor parte del trabajo consistía en configurar el 'hardware' al que accede el código para poder realizar pruebas de unidad / módulo de manera efectiva. Después de eso, es fácil agregar nuevos casos de prueba unitaria.

Como se mencionó anteriormente, es un marco de prueba de unidad C / C ++. Por lo tanto, necesitará un compilador de C ++.

Guía del usuario de CxxTest Wiki de CxxTest

aparte de mi obvio sesgo

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

es una forma simple y agradable de probar el código C de la unidad. imita xUnit

Después de leer Minunit, pensé que una mejor manera era basar la prueba en una macro de afirmación que utilizo mucho como una técnica de programa defensivo. Entonces utilicé la misma idea de Minunit mezclado con la afirmación estándar. Puedes ver mi marco (un buen nombre podría ser NoMinunit) en el blog de k0ga

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

Google tiene un excelente marco de prueba. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

Y sí, por lo que veo, funcionará con C simple, es decir, no requiere características de C ++ (puede requerir un compilador de C ++, no estoy seguro).

Cmockery es un proyecto lanzado recientemente que consiste en una biblioteca C muy simple de usar para escribir pruebas unitarias.

Primero, mira aquí: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

Mi empresa tiene una biblioteca C que usan nuestros clientes. Utilizamos CxxTest (una biblioteca de prueba de unidad C ++) para probar el código. CppUnit también funcionará. Si está atascado en C, recomendaría RCUNIT (pero CUnit también es bueno).

Si está familiarizado con JUnit, le recomiendo CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Eso supone que tiene un compilador de c ++ para hacer las pruebas unitarias. si no, tengo que estar de acuerdo con Adam Rosenfield en que ese cheque es lo que quieres.

Utilicé RCUNIT para hacer algunas pruebas unitarias para el código incrustado en la PC antes de probar en el objetivo. La buena abstracción de la interfaz de hardware es importante; de ​​lo contrario, la endianidad y los registros mapeados en memoria lo matarán.

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

API Sanity Checker : marco de prueba para bibliotecas C / C ++:

Un generador automático de pruebas unitarias básicas para una biblioteca C / C ++ compartida. Es capaz de generar datos de entrada razonables (en la mayoría de los casos, pero desafortunadamente no todos) para parámetros y componer casos de prueba simples ("sanidad" o "poca profundidad") para cada función en la API a través del análisis de declaraciones en el encabezado archivos.

La calidad de las pruebas generadas permite verificar la ausencia de errores críticos en casos de uso simples. La herramienta es capaz de construir y ejecutar pruebas generadas y detectar fallas (segfaults), abortos, todo tipo de señales emitidas, código de retorno de programa distinto de cero y bloqueo de programa.

Ejemplos:

• Conjunto de pruebas para fontconfig 2.8.0
• Conjunto de pruebas para FreeType 2.4.8

Una técnica para usar es desarrollar el código de prueba de la unidad con un marco de trabajo de C ++ xUnit (y compilador de C ++), mientras se mantiene la fuente para el sistema de destino como módulos de C.

Asegúrese de compilar regularmente su fuente C bajo su compilador cruzado, automáticamente con sus pruebas unitarias si es posible.

LibU ( http://koanlogic.com/libu ) tiene un módulo de prueba unitaria que permite dependencias explícitas de conjuntos de pruebas / casos, aislamiento de pruebas, ejecución paralela y un formateador de informes personalizable (los formatos predeterminados son xml y txt).

La biblioteca tiene licencia BSD y contiene muchos otros módulos útiles: redes, depuración, estructuras de datos de uso común, configuración, etc., en caso de que los necesite en sus proyectos ...

Me sorprende que nadie haya mencionado Cutter (http://cutter.sourceforge.net/) . Puede probar C y C ++, se integra a la perfección con las herramientas automáticas y tiene un tutorial realmente agradable disponible.

En caso de que esté apuntando a plataformas Win32 o al modo de kernel NT, debe echar un vistazo a cfix .

Si todavía está buscando marcos de prueba, CUnitWin32 es uno para la plataforma Win32 / NT.

Esto resuelve un problema fundamental que enfrenté con otros marcos de prueba. Es decir, las variables globales / estáticas se encuentran en un estado determinista porque cada prueba se ejecuta como un proceso separado.