Hay muchas variables que determinarán el mejor marco de pruebas unitarias 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 un 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 tiene solo 3 líneas es Minunit .
He encontrado que las pruebas unitarias usando el microcontrolador como objetivo son bastante engorrosas, ya que necesita poder presentar un entorno adecuado para descargar pruebas, ejecutarlas y luego obtener resultados. Simplemente poner la plataforma en su lugar que le permitirá hacer esto es una gran tarea.
Otro enfoque que he adoptado 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. Como está utilizando gcc para el destino, el código también debe compilarse en el host.
Las pruebas en el host de compilación generalmente son mucho más fáciles ya que tiene el soporte completo del sistema operativo host y todas sus herramientas. Por ejemplo, cuando pruebo 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 de host utiliza paquetes UDP para simular la transferencia inalámbrica de paquetes, y el controlador simulado admite la capacidad de descartar paquetes para que pueda probar mis protocolos.
En el producto en el que estaba trabajando, se estaba utilizando un sistema operativo con subprocesos, por lo que la capa de abstracción para probar en el sistema operativo host usó pthreads en su lugar.
Si bien 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. Otro beneficio de tener el código ejecutado en diferentes plataformas es probar que el código es portátil. Recogerá rápidamente errores endianos si las arquitecturas objetivo y host difieren.
Ahora estoy un poco fuera de tema, pero siento que estas ideas pueden ayudarlo con su elección del marco de prueba y los métodos de prueba.