Hay muchas variables que determinarán el mejor marco de pruebas de unidad para usar en su situación. Algunos elementos que pueden afectar su elección serán:
- El idioma de destino.
- ¿Qué soporte de biblioteca está disponible? por ejemplo, libc o una versión reducida del mismo.
- El sistema operativo del objetivo. por ejemplo, Ninguno, FreeRTOS, personalizado.
La mayoría de los marcos de tipo xUnit proporcionarán algún nivel básico de funcionalidad que puede ser útil. He usado Cunit con cierto éxito en el pasado. (paquete libcunit1-dev en Ubuntu / Debian). La mayoría de los marcos requerirán que libc esté disponible, algunos requerirán soporte adicional del sistema operativo.
Otra alternativa que solo tiene 3 líneas es Minunit .
Descubrí que las pruebas de unidad que utilizan el microcontrolador como objetivo son bastante engorrosas, ya que es necesario presentar un entorno adecuado para descargar pruebas, ejecutarlas y luego obtener resultados. Solo poner la plataforma en su lugar que le permitirá hacer esto es una gran tarea.
Otro enfoque que he tomado y que me ha funcionado es realizar pruebas unitarias en el host, implementando una capa de abstracción entre los controladores y el código de la aplicación. Ya que estás usando gcc para el destino, el código también debe compilarse en el host.
En general, las pruebas en el host de compilación son mucho más fáciles, ya que cuenta con el soporte completo del SO host y todas sus herramientas. Por ejemplo, al realizar pruebas en el host, tengo una versión simulada de mi controlador inalámbrico con la misma interfaz que el controlador real que se ejecuta en el destino. La versión del host utiliza paquetes UDP para simular la transferencia inalámbrica de paquetes, con el controlador simulado que admite la capacidad de descartar paquetes para que pueda probar mis protocolos.
En el producto en el que estaba trabajando, se estaba usando un sistema operativo de subprocesos, por lo que la capa de abstracción para las pruebas en el sistema operativo host usaba pthreads en su lugar.
Aunque no es perfecto, cuanto más fácil sea para usted escribir y ejecutar pruebas, es más probable que implemente más casos de prueba. Otra ventaja de tener el código ejecutado en diferentes plataformas es probar que el código es portátil. Recogerá rápidamente los errores de Endian si las arquitecturas de destino y host difieren.
Ahora estoy un poco fuera de tema, pero creo que estas ideas pueden ayudarte con tu elección del marco de prueba y los métodos de prueba.