Lo que estás describiendo como un flujo de trabajo no es, en mi opinión, el Espíritu de TDD.
La sinopsis del libro de Kent Beck en Amazon dice:
Muy simple, el desarrollo guiado por pruebas está destinado a eliminar el miedo en
desarrollo de aplicaciones. Aunque un poco de miedo es saludable (a menudo se lo ve como un
conciencia que le dice a los programadores que "¡cuidado!"), el autor
cree que los subproductos del miedo incluyen tentativo, gruñón y
Programadores no comunicativos que son incapaces de absorber constructivos.
crítica. Cuando los equipos de programación compran en TDD, ven inmediatamente
resultados positivos. Eliminan el miedo involucrado en sus trabajos, y
Están mejor equipados para enfrentar los difíciles desafíos que enfrentan.
TDD elimina los rasgos tentativos, enseña a los programadores a
Comunicarse, y alienta a los miembros del equipo a buscar críticas.
Sin embargo, incluso el autor admite que el mal humor debe ser resuelto
¡individualmente! En resumen, la premisa detrás de TDD es que el código debe ser
continuamente probado y refactorizado.
TDD práctico
Pruebas automáticas formales, especialmente las Pruebas unitarias, cada método de cada clase es tan malo como un anti-patrón y no prueba nada. Hay un equilibrio que se tendrá. ¿Estás escribiendo pruebas unitarias para cada método setXXX/getXXX
, también son métodos?
Las pruebas también pueden ayudar a ahorrar tiempo y dinero, pero no olvide que su desarrollo y su costo son de código y, por lo tanto, cuestan tiempo y dinero de mantenimiento. Si se atrofian por falta de mantenimiento, se convierten en una responsabilidad más que en un beneficio.
Al igual que todo esto, hay un balance que no puede ser definido por nadie más que por ti mismo. Cualquier dogma de cualquier manera es probablemente más incorrecto que correcto.
Una buena métrica es el código que es crítico para la lógica de negocios y está sujeto a modificaciones frecuentes según los requisitos cambiantes. Esas cosas requieren pruebas formales que sean automatizadas, lo que sería un gran retorno de la inversión.
Será muy difícil encontrar muchas tiendas profesionales que funcionen de esta manera. Simplemente no tiene sentido comercial gastar dinero probando cosas que, para todos los propósitos prácticos, nunca cambiarán después de que se realice una simple prueba de humo. Escribir pruebas formales automatizadas de unidades para los métodos .getXXX/.setXXX
es un buen ejemplo de esto, una completa pérdida de tiempo.
Hace ya dos décadas que se señaló que las pruebas del programa
puede demostrar convincentemente la presencia de errores, pero nunca puede
demostrar su ausencia. Después de citar este comentario tan publicitado.
devotamente, el ingeniero de software vuelve al orden del día y
continúa refinando sus estrategias de prueba, al igual que el alquimista de
Ayer, quien continuó refinando sus purificaciones crisocósmicas.
- Edsger W. Djikstra . (Escrito en 1988, por lo que ahora está más cerca de
4.5 décadas.)
Consulte también esta respuesta .