Vea también el intento de Ron Jeffries de crear un solucionador de Sudoku con TDD , que desafortunadamente no funcionó.
El algoritmo requiere una comprensión significativa de los principios de diseño de algoritmos. Con estos principios, de hecho, es posible proceder gradualmente, con un plan, como lo hizo Peter Norvig .
De hecho, para algoritmos que requieren un esfuerzo de diseño no trivial, casi siempre es que el esfuerzo es de naturaleza incremental. Pero cada "incremento", que es pequeño a los ojos de un diseñador de algoritmos, parece un salto cuántico (para tomar prestada su frase) a una persona que no ha tenido la misma experiencia o conocimiento con esta familia particular de algoritmos.
Esta es la razón por la cual una educación básica en teoría CS combinada con mucha práctica de programación de algoritmos es igualmente importante. Saber que existe una "técnica" particular (pequeños bloques de construcción de algoritmos) es un largo camino para hacer estos saltos cuánticos incrementales.
Sin embargo, existen algunas diferencias importantes entre el progreso incremental en algoritmos y TDD.
JeffO ha mencionado una de las diferencias : una prueba que verifica la exactitud de los datos de salida es independiente de una prueba que afirma el rendimiento entre diferentes implementaciones del mismo algoritmo (o diferentes algoritmos que compiten para dar la misma solución).
En TDD, uno agrega un nuevo requisito en la forma de una prueba, y esta prueba inicialmente no pasará (rojo). Entonces se cumple el requisito (verde). Finalmente el código se refactoriza.
En el desarrollo de algoritmos, el requisito generalmente no cambia. La prueba de verificación de la corrección del resultado se escribe primero o poco después de que se complete un borrador (altamente seguro pero lento) de la implementación del algoritmo. Esta prueba de corrección de datos rara vez se cambia; uno no lo cambia para fallar (rojo) como parte del rito TDD.
Sin embargo, en este aspecto, el análisis de datos es claramente diferente del desarrollo de algoritmos, porque los requisitos de análisis de datos (tanto los conjuntos de entrada como los resultados esperados) solo se definen libremente en la comprensión humana. Por lo tanto, los requisitos cambian con frecuencia a nivel técnico. Este cambio rápido coloca el análisis de datos en algún lugar entre el desarrollo de algoritmos y el desarrollo de aplicaciones de software en general, aunque aún requiere mucho algoritmo, los requisitos también están cambiando "demasiado rápido" al gusto de cualquier programador.
Si el requisito cambia, normalmente requiere un algoritmo diferente.
En el desarrollo de algoritmos, cambiar (ajustar) la prueba de comparación de rendimiento para que falle (rojo) es una tontería: no le da ninguna idea sobre los posibles cambios en su algoritmo que mejorarían el rendimiento.
Por lo tanto, en el desarrollo de algoritmos, tanto la prueba de corrección como la prueba de rendimiento no son pruebas TDD. En cambio, ambas son pruebas de regresión . Específicamente, la prueba de regresión de corrección le impide realizar cambios en el algoritmo que romperá su corrección; la prueba de rendimiento le impide realizar cambios en el algoritmo que lo hará correr más lento.
Todavía puede incorporar TDD como un estilo de trabajo personal, excepto que el ritual "rojo - verde - refactor" no es estrictamente necesario ni particularmente beneficioso para el proceso de pensamiento del desarrollo de algoritmos.
Yo diría que las mejoras en el algoritmo en realidad resultan de realizar permutaciones aleatorias (no necesariamente correctas) a los diagramas de flujo de datos del algoritmo actual, o mezclarlas y combinarlas entre implementaciones previamente conocidas.
TDD se utiliza cuando hay múltiples requisitos que se pueden agregar de forma incremental a su conjunto de prueba.
Alternativamente, si su algoritmo está basado en datos, cada pieza de datos de prueba / caso de prueba se puede agregar de forma incremental. TDD también sería útil. Por esta razón, un enfoque "similar a TDD" de "agregar nuevos datos de prueba - mejorar el código para que maneje estos datos correctamente - refactorizar" también funcionará para el trabajo de análisis de datos abierto, en el que los objetivos de los algoritmos se describen en humanos palabras céntricas y su medida de éxito también juzgadas en términos humanos definidos.
Pretende enseñar una manera de hacerlo menos abrumador que tratar de satisfacer todos (docenas o cientos) de requisitos en un solo intento. En otras palabras, TDD está habilitado cuando puede dictar que ciertos requisitos u objetivos de estiramiento pueden ignorarse temporalmente mientras implementa algunos borradores iniciales de su solución.
TDD no es un sustituto de la informática. Es una muleta psicológica que ayuda a los programadores a superar el impacto de tener que satisfacer muchos requisitos a la vez.
Pero si ya tiene una implementación que da el resultado correcto, TDD consideraría su objetivo cumplido y el código listo para ser entregado (para refactorizar, o para otro usuario programador). En cierto sentido, lo alienta a que no optimice prematuramente su código, al darle objetivamente una señal de que el código es "suficientemente bueno" (para pasar todas las pruebas de corrección).
En TDD, también se enfoca en los "microrequisitos" (o cualidades ocultas). Por ejemplo, validaciones de parámetros, aserciones, lanzamiento y manejo de excepciones, etc. TDD ayuda a garantizar la corrección de las rutas de ejecución que no se ejercen con frecuencia en el curso normal de la ejecución del software.
Ciertos tipos de código de algoritmo también contienen estas cosas; estos son susceptibles a TDD. Pero debido a que el flujo de trabajo general del algoritmo no es TDD, tales pruebas (en validaciones de parámetros, afirmaciones y manejo y excepción de excepciones) tienden a escribirse después de que el código de implementación ya se ha escrito (al menos parcialmente).