Los pros y los contras son en gran medida los mismos para los embebidos o no emebdded.
En 1999, cuando vi a Kent Beck demostrar la primera programación de prueba en Java usando JUnit, me di cuenta de que esta práctica realmente podría ayudar con algunos de los problemas fundamentales que enfrentan los desarrolladores integrados.
Para empezar, solíamos desarrollar código sin dónde ejecutarlo. El hardware y el software se desarrollaron simultáneamente. Si teníamos hardware, a menudo tenía errores propios, o no funcionaba como lo especificaba su especificación.
- ¿Cuáles son los mejores institutos de capacitación para IoT y sistemas integrados en India?
- ¿Qué debo elegir como carrera entre robótica y sistema embebido?
- ¿Cuáles son las diferencias entre 8051 microcontrolador y pic?
- ¿Qué flujo tiene más alcance en el futuro: diseño embebido o PCB? Obtuve un trabajo en PCB pero estoy muy interesado en la programación integrada.
- ¿Cuál es el papel del desarrollador del controlador del dispositivo en los sistemas integrados?
Hay otros problemas que enfrentan los desarrolladores integrados, colectivamente los llamo el cuello de botella de hardware objetivo que TDD puede ayudar a aliviar. El cuello de botella está formado por:
- El hardware que no existe.
- El hardware que tiene defectos propios.
- Edición larga, construcción, implementación, ejecución de ciclos.
- Tengo datos en mi sitio web recopilados de cientos de desarrolladores integrados que toman mi curso de capacitación sobre cómo desperdician la espera de que se complete este ciclo (práctica actual de los asistentes de capacitación de Wingman Software).
- El entorno de depuración en destino es un desafío
- Por ejemplo, puede romper el código que está depurando, pero las rutinas de interrupción aún se están ejecutando, o el punto de interrupción puede activar el temporizador de vigilancia para que lo devuelva para comenzar.
- A partir de mis datos, veo que los desarrolladores integrados viven con este problema como si no pudieran hacer nada al respecto.
- Recursos informáticos limitados (E / S, RAM, ROM, tiempo)
- El primer sistema en el que trabajé ni siquiera tenía un puerto serie para mensajes de depuración.
- Si tenía uno, no teníamos suficiente ROM para almacenar mensajes de depuración o agregar mucho código de depuración.
Lo que me llamó la atención del TDD de Kent en Java usando JUnit, es que no tuve que soportar el cuello de botella del hardware de destino cuando el código funcionaba. Podría trabajar en el ciclo de retroalimentación rápida de TDD en mi sistema de desarrollo y construir código que haga lo que creo que se supone que debe hacer.
Uno de los desafíos de TDD es dónde usarlo, dónde no usarlo y cómo usarlo dada su situación actual.
Por ejemplo, recientemente he estado trabajando en un prototipo de IoT. Gran parte del trabajo pesado lo realiza el entorno de los proveedores y me permite programar mi aplicación en python. Inicialmente, tuve que descubrir cómo funcionaba este entorno y luego evolucionarlo para hacer algo de lo que necesitaba. Obtuve el código para trabajar e hice un desastre. Pero ahora podía ver lo que se necesitaba, y en lugar de vivir en el desastre que creé mientras aprendía, comencé a separar la mayor parte de mi aplicación del marco del proveedor. Utilicé TDD para ayudarme a refactorizar y diseñar una separación decente de las preocupaciones.
Algunas de las cosas de bajo nivel solo se prueban en el entorno de destino. Hago mi mejor esfuerzo para mantener este código de línea recta sin decisiones (mi experiencia al ver el código del programador es que los programadores no son tan buenos en la lógica condicional). Trato de hacerlo para que el código que no tiene pruebas automatizadas sea el menos probable que deba cambiarse. Un gran profesional de TDD es que la red de seguridad me ayuda cuando quiero mejorar el diseño. También me ayuda a buscar casos límite y construir mejores interfaces (desea obtener más información, consulte TDD Guided by ZOMBIES).
Específicamente, usted preguntó sobre “aplicaciones de firmware, RTOS, Embedded OS o Linux y controladores de kernel, así como sus aplicaciones en electrónica de misión crítica, seguridad, seguridad y ordinaria”.
firmwares de metal desnudo
Si está haciendo un trabajo de configuración de E / S, como la programación y el controlador de interrupción, una vez que lo hace correctamente, nunca lo cambia hasta la próxima revolución de hardware, que tampoco tiene lógica condicional, no me molestaría en escribir pruebas para eso.
Si estoy creando un controlador de dispositivo más complejo (en mi libro Test-Driven Development for Embedded CI utilizo un controlador flash como ejemplo), puedo realizar una prueba de manejo hasta las operaciones de lectura y escritura de E / S y obtener el código haz lo que dice la especificación. Los simulacros son una gran herramienta para probar controladores de dispositivos donde cada interacción de hardware y su orden son críticos. En el momento de la integración, descubrirás dónde malinterpretaste la especificación o dónde está mal. Luego haces que las pruebas coincidan con la realidad en los lugares donde no lo hicieron.
También tienes otro gran profesional aquí, sabes lo que está haciendo tu código, en lugar de tener tanto hardware sospechoso como software sospechoso.
RTOS, aplicaciones Embedded OS o Linux y controladores de kernel
En el código de prueba de unidad que interactúa con el sistema operativo, sea cual sea su sabor, TDD recomienda algo que debe hacer independientemente de TDD; Aplicación separada / lógica empresarial de los mecanismos de concurrencia. Lo que eso significa es que abstraerá y bloqueará las interacciones del sistema operativo en las pruebas unitarias TDD. Muchas aplicaciones integradas se crean en torno a la transmisión de mensajes. Para probar una tarea que espera un mensaje y actúa sobre el mensaje tal vez enviando otros mensajes, falsificar el mensaje es justo lo que necesita para ejercer su lógica comercial.
Lo que no mencionaste fueron las condiciones de carrera. Si no conoce una condición de carrera, TDD no las encontrará ni eliminará mágicamente. Pero si conoce una condición de carrera, puede escribir pruebas para asegurarse de que su código cubra las carreras. Si se sorprende por una condición de carrera y ahora tiene que agregar complejidad a su código para manejar la carrera, tiene su conjunto de pruebas para ayudarlo a preservar todos los otros comportamientos deseados mientras prueba en el manejo de la raza recién descubierta.
misión crítica, seguridad, seguridad
Lo mejor que puede hacer TDD es asegurarse de que su código esté haciendo lo que cree que debe hacer (¡y eso es bastante bueno!). Siempre hay dos lados para “misión crítica, seguridad, seguridad”. Un lado son los requisitos de la aplicación. Por ejemplo, los programadores necesitan conocer los problemas de seguridad de la aplicación, como: los pacientes solo estarán expuestos a ‘tantas’ unidades de algo malo. Las pruebas se pueden escribir en torno a estos requisitos conocidos.
El otro lado es el riesgo implementado. Si su código explota mientras el tubo de rayos X está energizado y usted fríe al paciente, no es porque haya ignorado el requisito. Este es un comportamiento involuntario causado por un código fuera de control. (ve a leer sobre la aceleración involuntaria de Toyota)
En cualquier caso, creo que dado el rigor de TDD y la seguridad adicional que proporciona sobre la programación de depuración posterior, creo que es una muy buena opción para mejorar los atributos “misión crítica, seguridad, seguridad”. A menudo, las características funcionan por accidente. Dos defectos de compensación permiten que una característica funcione. Prefiero que mis funciones funcionen a propósito, donde mi código está haciendo lo que creo que se supone que debe hacer.
Conclusión
La mayor desventaja de TDD es que lleva tiempo aprenderlo y aprender dónde usarlo y dónde no usarlo. Lleva tiempo descubrir qué pruebas son buenas y cómo hacer que su código sea comprobable y probado. He escuchado pruebas de mantenimiento como una gran estafa. He descubierto que esto suele ser cierto si las pruebas están mal diseñadas con mucha duplicación, o las pruebas que se ejecutan demasiado.
Lo recogí rápidamente y obtuve beneficios rápidamente, pero todavía estoy aprendiendo 16 años después. He descubierto que produzco un mejor software más rápido usando TDD. Una vez que desarrolle la habilidad, el tiempo para escribir una prueba a menudo será menor que el tiempo para ejecutar una prueba manualmente.
