¿Qué marco de prueba de unidad puedo usar para un proyecto mcu basado en CA?


15

Estoy pensando en cómo puedo usar pruebas unitarias en mi proyecto mcu y qué marcos puedo usar para simplificarlo.

Hoy estoy usando un stm32 con OpenOCD-jtag desde una PC con Linux, donde todo se controla desde un Makefile clásico y se combina con gcc.

Podría crear algo yo mismo, pero si hay un marco que pueda usar, sería bueno. (Es una ventaja si el marco puede generar el resultado en un formato que Jenkins / Hudson pueda leer).

¿Hay alguna manera de usar un marco de prueba de unidad con un stm32?


3
No tengo tiempo para escribir una respuesta completa, pero he usado muchas de las herramientas y técnicas que se encuentran en estos documentos y en esta serie de blogs . En una palabra: CMock!
Kevin Vermeer

Respuestas:


4

Echa un vistazo a CppUTest, y el excelente http://pragprog.com/book/jgade/test-driven-development-for-embedded-c de James Grenning

CppUTest tiene soporte para C y C ++, y tiene un buen conjunto de plantillas Makefile que me ayudaron a comenzar bastante rápido.


Compré una versión de ePub, veamos si es bueno :)
Johan

El libro es bueno, pero creo que la unidad (el otro marco en ese libro) satisfará mejor mi necesidad.
Johan

Aceptado ya que el libro me empujó en la dirección correcta.
Johan

5

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.


He resuelto cómo obtengo código en el destino y puedo usar gdb en modo script para detenerme en diferentes puntos de interrupción como test_ok o test_fail ( fun-tech.se/stm32/TestSuite/index.php ). Así que estoy a medio camino. Esta es más una pregunta de cómo construir las diferentes "pruebas". Mis ideas hoy son un poco poco flexibles, es por eso que comencé a buscar algún tipo de marco.
Johan

1

Echa un vistazo a embUnit http://embunit.sourceforge.net/embunit/index.html . Es un marco de prueba de unidad C integrado con una huella baja.

Lo usamos con éxito en un par de proyectos de microcontroladores integrados. No espere las opciones y características que obtiene con un marco de prueba de unidad de escritorio. Pero definitivamente es lo suficientemente potente.

Tiene una gran cantidad de afirmaciones definidas para usted, por lo que no tiene que perder mucho tiempo escribiendo afirmaciones personalizadas como con minUnit.


1

Hace algún tiempo escribí un tutorial completo sobre el tema: Pruebas unitarias (incrustadas) de aplicaciones C con Ceedling ; Utilizo estas técnicas en muchos proyectos, y estoy muy feliz hasta ahora.


2
Esta es una respuesta de solo enlace, y como tal será inútil si la URL cambia o el enlace se cae. Debe explicar la información relevante en la respuesta , luego puede agregar el enlace como referencia.
tubería

2
@pipe Sí, pero la pregunta (recomendación del producto esencialmente) pide respuestas como esta.
Dmitry Grigoryev


-1

Prueba con pelusa, pero no creo que sea para pruebas unitarias, es para análisis de código.


2
El análisis de código estático no puede ayudar a ejecutar y probar el código, por lo que no es realmente útil.
Johan

1
Quizás no sea útil en el contexto de las pruebas unitarias, pero todos deberían usar algún tipo de herramienta de análisis estático.
Tim
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.