Desarrollo impulsado por prueba para bibliotecas de procesamiento de señal

Question

Trabajo con manipulación de audio, generalmente usando Matlab para creación de prototipos y C++ para implementación. Recientemente, he estado leyendo sobre TDD. He visto algunos ejemplos básicos y estoy bastante entusiasmado con el paradigma.

Por el momento, uso lo que consideraría un enfoque global "asistido por prueba". Para esto, escribo bloques de procesamiento de señales en C++, y luego hago un archivo simple de Matlab mex que puede interactuar con mis clases. Posteriormente agregué funcionalidad, comprobando que los resultados coinciden con un script de Matlab equivalente a medida que avanzo. Esto funciona bien, pero las pruebas se vuelven obsoletas rápidamente a medida que el sistema evoluciona. Además, estoy probando todo el sistema, no solo unidades.

Sería bueno utilizar un marco TDD establecido donde pueda tener un conjunto de pruebas, pero no veo cómo puedo validar la funcionalidad de los bloques de procesamiento sin pruebas que son tan complejas como el código bajo prueba . ¿Cómo generaría las señales de referencia en una prueba de C++ para validar un bloque de procesamiento sin que la prueba sea una forma de profecía autocumplida?

Si alguien tiene experiencia en esta área, o puede sugerir algunas metodologías que podría leer, sería genial.

Answer 1

Creo que es genial para aplicar el enfoque TDD al procesamiento de señales (que me habría ahorrado meses de tiempo si lo sabía hace años cuando estaba haciendo procesamiento de señal yo mismo). Creo que la clave es la de romper el sistema en los componentes de nivel más bajo que se pueden probar de forma independiente, por ejemplo:

• FFT: señales de prueba a frecuencias conocido: DC, fs/NFFT, Fs/2 y diferentes fases, etc. . Comprobar los picos y fase son como se espera, comprobar constante es como se espera
• pico de recolección de la normalización: prueba que correctamente encontrar máximos/mínimos
• Filtros: generar de entrada a frecuencias conocidas y comprobar la amplitud de salida y la fase es como se esperaba

Es poco probable conseguir exactamente los mismos resultados a cabo entre C++ y Matlab, por lo que tendrá que suministrar límites de error en algunas de las pruebas. TDD es una excelente forma de verificar no solo la exactitud del código que tienes, sino que también es muy útil al probar diferentes implementaciones. Por ejemplo, si desea reemplazar una implementación de FFT por otra, a menudo hay pequeñas diferencias con la forma en que se empacan los datos, o la constante de normalización que se usa. TDD le dará un alto grado de confianza en que la nueva biblioteca esté integrada correctamente.

Answer 2

Hago algo similar para la detección heurística, y tenemos montones y montones de archivos de captura y un marco para poder cargarlos e inyectarlos para probarlos. ¿Tiene la posibilidad de capturar las señales de referencia en un archivo y hacer lo mismo?

En cuanto a mis 2 centavos con respecto a TDD, es una gran manera de desarrollar, pero como con la mayoría de los paradigmas, no siempre hay que seguir al pie de la letra, hay momentos en los que debe saber cómo flexionar un poco las reglas , para no escribir demasiados códigos/pruebas desechables. Leí acerca de un enfoque que decía que absolutamente ningún código debería escribirse hasta que se desarrollara una prueba, que a veces puede ser demasiado estricta.

Por otro lado, siempre me gusta decir: "Si no es a prueba, sus roto" :)

Answer 3

Está bien que la prueba sea tan compleja o más compleja que el código en desarrollo.Si cambia (actualiza, refactoriza, corrige los errores) el código y no la prueba, la prueba de la unidad le advertirá que algo cambió y debe ser revisado (¿se corrigió el error del modo A al cambiar el modo B ?, etc.)

Además, puede mantener las API para los componentes de cómputo individuales, y no solo para el sistema completo de extremo a extremo.

Answer 4

Acabo de empezar a pensar en TDD en el contexto del procesamiento de señal, por lo que solo puedo agregar un poco a las respuestas anteriores. Lo que he hecho es explotar un poco la superposición para probar primitivas. Por ejemplo, al probar un filtro IIR, verifiqué de forma independiente los elementos b0, b1 y b2 con ganancias unitarias y escaladas, y luego verifiqué los elementos a1 y a2 que siguieron las desintegraciones modeladas fácilmente. Mi señal de prueba fue una combinación de funciones de rampa para el numerador y funciones de impulso para el denominador. Sé que es un ejemplo trivial, pero el proceso debería funcionar para muchas operaciones lineales. Las pruebas también deberían tener regiones inestables y mostrar que las salidas explotan adecuadamente.

En general, espero que las respuestas de impulso hagan mucho por mí, ya que muchas situaciones las reducirán a funciones trigonométricas, que se pueden calcular independientemente. De manera similar, si su operación tiene una expansión en serie, su función de prueba podría realizar la expansión en un orden relevante y comparar en contra de su bloque de procesamiento. Va a ser lento, pero debería funcionar.