En el notorious Stack Overflow #38 podcastJoel Spolsky hablamos de lo difícil que sería hacer TDD para algo así como la compresión JPEG. Bob Martin wanted to cover cómo hacer TDD para una instancia como la del podcast # 41, pero no creo que alguna vez hayan llegado a ella. Por lo tanto:compresión TDD y JPEG
¿Cómo se puede usar TDD para desarrollar y probar la compresión JPEG?
La pregunta de Joel fue algo como esto. Supongamos que desea establecer un poco en algún lugar que causó que se muestre una imagen de baja resolución en lugar de una imagen de alta resolución. ¿Cómo usarías TDD para que funcione? ¿Escribirías una prueba que raspa la pantalla para mostrar que la imagen estaba en baja resolución?
Por supuesto que no. Usted ya sabe que la biblioteca JPEG funciona. Usted ya sabe que si lo llama con los argumentos correctos se mostrará en baja resolución. Lo que necesita probar es que el bit que establece se traduce a las llamadas apropiadas a la biblioteca JPEG. Entonces se burla de la biblioteca JPEG con un módulo muy simple controlado por su prueba. Luego configura el bit y solicita visualización. La biblioteca Mocked JPEG recordará cómo fue llamada, y luego la prueba puede verificar para asegurarse de que fue llamada correctamente.
Bien, entonces, ¿cómo probarías las partes internas de la biblioteca JPEG? No sé mucho sobre el procesamiento de JPEG, pero supongo que se trata de compresión, descompresión y mapas de bits. La compresión y la descompresión son solo algoritmos. Los algoritmos tienen salidas predecibles a partir de entradas dadas.Así que configura una serie de entradas muy simples y se asegura de que obtenga los resultados predecibles. Configura las entradas para que se cubran las partes internas de los algoritmos JPEG. La misma lógica es válida para los mapas de bits. No tiene que renderizarlos en la pantalla. Los pequeños mapas de bits simples se pueden representar en memorias intermedias de memoria que las pruebas pueden examinar. Por simple, me refiero a SIMPLE. 3X3, 5X5, 8X8. Sencillo. Nuevamente, estructura los datos de entrada para cubrir la mayor parte del código.
Nada de esto es ciencia de cohetes. Ninguno si es perfecto Pero un conjunto de 50 pruebas que demuestra que el 90% de su lógica es correcta puede marcar una gran diferencia cuando desee realizar cambios.
¿Puede eliminar completamente las pruebas manuales? Por supuesto no. Pero puede mitigarlo significativamente. Puede reducir las pruebas manuales a unas pocas pruebas muy estratégicas en lugar de miles de planes de prueba tediosamente tediosos.
Impresionante, conseguí que el tío Bob se uniera a stackoverflow. Debería haber una insignia para esto. – stimms
Jaja ... bueno, ya que no obtendrás una insignia, al menos le daré un +1 a tu pregunta. –
Puede renderizar imágenes más complejas y luego calcular una suma de comprobación MD5 para comparar con resultados conocidos. –
Si piensa que TDD significa que las pruebas vienen antes que cualquier código o diseño, es en gran medida imposible. Para algoritmos complejos, necesitas algunos resultados. Y en el caso de la compresión, los resultados son difíciles de producir a mano. No imposible, pero difícil.
Además, la compresión requiere un algoritmo de muy alto rendimiento. Simplemente pasar una prueba no es lo suficientemente bueno. Muchos algoritmos de bajo rendimiento pueden pasar la prueba básica de "corrección".
Para ir más allá de lo correcto, necesita pruebas de que su algoritmo sea óptimo. Esto solo puede desarrollarse fuera de la vista mundial de prueba. Necesita un análisis de complejidad utilizando O (algo), que no es el resultado de una prueba; ni puede ser bien definido como los resultados de una prueba.
Si, por otro lado, cree que la "capacidad de prueba" es anterior a la mayoría del código, entonces es fácil.
Diseñe su algoritmo. Escribe una prueba de que es óptimo.
Escriba un código que expone las piezas críticas de su algoritmo como módulos comprobables.
En algunos casos, escriba el código para producir resultados de prueba para el algoritmo general. Esto puede ser un código subóptimo de fuerza bruta que produce la respuesta correcta a través de algoritmos realmente obvios pero lentos.
Ensamble una prueba unitaria para mostrar que su implementación produce los resultados de prueba esperados.
Ensamble un documento técnico para mostrar que también es óptimo.
No es de prueba primero. Pero está basado en pruebas.
prueba de conducción del desarrollo no es solamente la programación, hay muchas otras cosas que puede hacer mediante la prueba en primer lugar, los ejemplos son con TDD aceptación, etc.
pensar primero cómo desea que se comporte, esta es la cosa. Para un algoritmo, un ejemplo podría ser algo como:
creo que es sólo una forma de vida para pensar con claridad lo que quiere lograr: D
Y por favor, podemos partir de ahora * siempre * se refieren a ella como 'The Notorious Stackoverflow # 38' o TNS # 38 ;-) –