¿Cómo probar el código de procesamiento de imagen de la unidad?

Estoy trabajando en el procesamiento de imágenes (principalmente OCR) y me pregunto cómo debería integrar las pruebas unitarias en mi desarrollo.

Ya estoy usando pruebas unitarias para un tipo de código más "común", pero cuando trato con código de procesamiento de imágenes no estoy seguro de cómo tratarlo. Este tipo de código siempre necesita algo de entrada / salida de datos de imagen y burlarse de esto no es obvio. Por ahora, principalmente estoy haciendo pruebas de integración, pero tardan un tiempo en ejecutarse y me gustaría tener algunas ideas sobre cómo dividir este tipo de código en pruebas unitarias para poder ejecutarlas más rápidamente.

Editar: el análisis de un personaje puede pasar por muchos pasos que involucran múltiples operaciones de rotación, escala y morfología. Estos pasos cambian a menudo a medida que se desarrolla el algoritmo. Por lo tanto, la entrada y la salida esperada pueden evolucionar mucho durante las pruebas. Cada carácter puede tener 100x100 píxeles, por lo que no es posible codificarlos en el código o trabajar con los datos generados.

— rold2007
fuente

¿Puedes dibujar un ejemplo de una función en la que tengas problemas para crear una prueba unitaria?

— Doc Brown

Demasiado corto para una respuesta real y no realmente pruebas unitarias: estamos procesando datos a mano (como en: pasar por una gran cantidad de muestra; generalmente voy más allá de 1000 para tales tareas de clasificación, pero depende del tamaño total de la muestra ) y comparar los resultados finales con los datos procesados a mano automáticamente. He configurado un pequeño marco para hacer esto, será de código abierto en unas pocas semanas, pero esta es la descripción: podría clonar el proceso: birgitplays.wordpress.com/2012/09/15/…

— Birgit P.

Para su ejemplo, podría probar fácilmente la rotación, el escalado, etc. como pequeñas unidades de prueba. Girar una imagen dada 45 grados no debería cambiar mucho. Esto también se aplica a las operaciones de escala y morfológicas. Sin embargo, probar algo donde la salida esperada evoluciona durante la implementación es difícil. Podría intentar hacer una medida de calidad y decir calidad> = some_quality. Para asegurarse de que su calidad no se degrada, pero esto también puede ser difícil. Aparte de eso, todo lo que puede hacer es tener pruebas que demuestren que las partes subyacentes no están rotas. Como escalar / rotar / etc.

— Martiert

@martiert: no estoy probando la rotación, el escalado, etc., ya que los llamo desde una tercera biblioteca que creo que está bien probada. El algoritmo OCR se compone de muchas de estas operaciones. Pero como usted dice, es difícil probar algo donde evoluciona una salida. Tal vez sea una buena advertencia de que no tenemos la opción que depender de las pruebas de integración ...

— rold2007

@Birgit P .: Solución interesante. Como dices, todavía es una prueba de integración. Tener un marco como la suya ayudaría a la creación de estas pruebas más rápido, pero no funcionará más rápido ...

— rold2007

Trabajo con software de grabación / análisis / transmisión de video y enfrentamos un problema muy similar. A continuación se muestra nuestra solución, no estoy seguro de cómo funcionará a largo plazo, pero por ahora parece funcionar.

Guarde las imágenes de entrada / salida como recursos en su proyecto de prueba de unidad. Luego, haga que la prueba unitaria verifique que cuando se proporciona una entrada específica, se produce esa salida específica.

9/10 veces cuando refactoriza el código y agrega otra funcionalidad, es de esperar que el comportamiento de sus rutinas de manejo de imágenes no cambie, por lo que si de repente todas las pruebas unitarias comienzan a fallar, es probable que se deba a un error.

Por otro lado, si realiza cambios en el algoritmo real, eso también dará como resultado una falla en la prueba de la unidad. En este caso, tendría que verificar manualmente / visualmente que los resultados son correctos y, si se ven bien, actualizar los recursos de imagen para que la prueba de la unidad pase nuevamente.

En nuestro proyecto, terminamos desarrollando fuentes de video "falsas" (o simulacros si lo desean), que pueden proporcionarnos datos tanto de entrada como de salida. Pero los datos en sí no son falsos, en realidad se capturaron utilizando clases de registro de datos auxiliares de un sistema en ejecución cuando realizamos pruebas manuales y verificamos que todo funcionaba.

— DXM
fuente

De acuerdo, está bien confiar en algunos archivos concretos en sus pruebas cuando está probando rutinas que trabajan con archivos (lo ve más a menudo con las pruebas de integración).

— Kemoda

Si ejecuta alguna entrada a través de toda la cadena de procesamiento y luego verifica la salida, no está realizando pruebas unitarias sino pruebas de integración.

— tdammers

@tdammers: nunca dije que lo ejecutara en toda la cadena. Ejecute alguna entrada a través de una "unidad", no toda la cadena. Y claro, si la salida de eso es algo más que imágenes, entonces solo necesita tener la entrada guardada como recursos de imagen.

— DXM

@DXM: entiendo su solución, pero creo que es posible que no tengamos las mismas restricciones. Mis datos de entrada / salida cambian mucho mientras se desarrolla el algoritmo. ¿Cómo afrontas estos cambios regulares? En OCR puedo tener más de 99% de precisión lo que las pruebas en sólo un par de imágenes me puede dar una falsa sensación de éxito, mientras que las pruebas de integración Me podrían decir más tarde que en realidad empeoró el algoritmo ...

— rold2007