¿Es una buena idea hacer TDD en componentes de bajo nivel?

Estoy considerando escribir un controlador de bajo nivel o componentes / núcleos del sistema operativo.

La gente de osdev.org parece pensar que las partes importantes no son significativamente verificables de esta manera, pero he leído algunas discusiones donde la gente pensaba de manera diferente. He mirado a mi alrededor, pero no he podido encontrar ejemplos reales de TDD en componentes de bajo nivel.

¿Es esto algo que la gente realmente hace, o simplemente algo de lo que la gente habla en teoría porque no hay una buena manera de hacerlo en la práctica?

Si estás interactuando o controlando hardware, entonces es difícil probar sin él. Puede intentar emular el hardware, pero eso es a menudo más difícil que escribir el controlador en primer lugar, por lo que termina sin saber si el error está en su controlador o en su emulador.

Personalmente, creo que uno puede obtener muchos de los beneficios de TDD (sin adherirse a TDD), al:

• Escrito, tanto al que llama y el abonado llamado código o menos al mismo tiempo (definitivamente no más de 24 horas de diferencia).
  • Y use eso para influir en el diseño de la interfaz (objetos, llamadas a métodos y parámetros).
• Para un componente que requiere un algoritmo / código complicado, considere primero implementarlo en un algoritmo más simple pero correcto, incluso si es menos eficiente (o estúpido, o solo funciona en una situación más limitada).
  • Un método de prueba muy simple sería ejecutar ambos algoritmos y comparar sus resultados.
• Una vez que se descubrió un error (por cualquier medio) en una parte del código, esa parte del código merece ser probada de manera mucho más agresiva. Esto significa hacer pruebas más sofisticadas de las que TDD requeriría. (basado en el razonamiento de que los errores ocurren en grupos )

TDD parece requerir que usted tenga una comprensión bastante clara de qué función planea implementar o qué requisitos planea satisfacer al implementar el código. En algunas situaciones, simplemente hay muy poca comprensión del problema. Esto habría requerido una solución de Spike . Dentro del alcance de esta solución de Spike, se puede aplicar TDD porque el problema se ha reducido a un nivel manejable. Una vez que se hayan terminado algunos Spikes, cada uno cubriendo algunos aspectos del problema original, uno puede comenzar a trabajar en la solución completa, y la aplicación de TDD en ese punto podría ser factible debido a la mejor comprensión.

Editado:

Después de leer la página con más cuidado,

Si bien debería ser posible probar la mayoría de las funciones del kernel en un controlador de prueba "testbed", las cosas realmente "jugosas" como el manejo de interrupciones, el despacho de procesos o la administración de memoria probablemente no sean comprobables por unidad. --- de http://wiki.osdev.org/Unit_Testing

Están diciendo claramente que la mayoría de las partes son comprobables, y que algunas partes requieren un tipo diferente de prueba: Prueba de esfuerzo .

Yo no. En el código incrustado de mi Maestro, simplemente escribo el código y paso mi tiempo razonando sobre lo que hace (y no hace). No estoy seguro de que se pueda hacer en mi caso de todos modos, me estoy acercando inquietantemente al límite físico de la memoria sin inyectar el código de prueba.

Creo que para sistemas que son lo suficientemente grandes (es decir, tienen MB de memoria, no KB), se puede hacer para algunos componentes si tiene suficiente tiempo y esfuerzo. Probar el código de lectura de pines burlándose de los pines es ... er ... no muy significativo. Si ha separado su lógica lo suficiente, puede probar la lógica en otro lugar.

FWIW, no compro TDD en el caso general: funciona bien para pilas de sistemas que son lo suficientemente grandes con suficientes recursos con suficiente comportamiento determinista, aparte de eso no parece una práctica razonable.