La gente dice que "hablar sobre TDD apenas funciona, si quieres convencer a alguien de TDD, muéstrale los resultados". Sin embargo, ya estoy obteniendo excelentes resultados sin TDD. Mostrándome que las personas que usan TDD obtienen buenos resultados no serán convincentes, quiero ver que las personas que escriben tanto TDD como no TDD obtengan mejores resultados con TDD.
A pesar de todo esto, estoy interesado en probar TDD. Sin embargo, no estoy convencido de que gane nada de esto. Si resulta útil, intentaré llevarlo al resto de mi equipo.
Mi pregunta principal es esta: ¿serviría TDD para algún propósito del código, si ya puedo probar la corrección del código?
Obviamente, ninguno de los dos es una bala de plata. Su prueba puede estar equivocada porque omitió un detalle, y su prueba podría fallar al detectar un error que no pudo probar. Al final, somos humanos, nadie puede hacer código 100% libre de errores para siempre. Solo podemos esforzarnos por acercarnos lo más posible.
Sin embargo, ¿TDD realmente ahorraría tiempo en código que tuviera su corrección probada? es decir, código que, en la máquina de estado en la que opera el código, todos los estados posibles válidos y sus rangos son reconocidos por el desarrollador, todos se tienen en cuenta y el código está diseñado en una verificación de errores de estilo de lista blanca que pasa todas las excepciones a un controlador superior para asegurarse de que no haya fugas inesperadas -> sin mostrar un mensaje relevante (dentro de lo razonable) al cliente y sin enviar notificaciones de registro a un administrador.
Las respuestas con ejemplos de la vida real serían mejores.
Algunas aclaraciones:
Esta pregunta no se trata de si puede probar la corrección del código o no. Asumamos por defecto que no todo el código puede probarse correcto dentro de un plazo razonable, pero que algunos fragmentos de código pueden serlo. Por ejemplo, es muy fácil comprobar la corrección de un módulo FizzBuzz. No es muy fácil para un servicio de sincronización de datos basado en la nube.
Dentro de este límite, la pregunta plantea lo siguiente: Comience con la suposición de que una base de código se divide en 2 partes: [I] partes que se han demostrado correctas [II] partes que no se han demostrado correctas, pero que se probaron manualmente para que funcionen.
Quiero aplicar prácticas TDD a esta base de código que no las tenía hasta ahora. La pregunta es la siguiente: ¿se debe aplicar TDD a cada módulo o sería suficiente aplicarlos solo a los módulos que no se probaron correctamente?
"Probado correcto" significa que puede considerar este módulo con un estilo completamente funcional, es decir, no se basa en ningún estado global o externo fuera de sí mismo, y tiene completamente su propia API para E / S que deben seguir otros módulos que interactúan con él. . No es posible "romper este módulo" cambiando el código fuera del módulo, en el peor de los casos, puede usarlo mal y recibir mensajes de error formateados.
Obviamente, cada regla tiene excepciones, los errores del compilador en las nuevas versiones del compilador pueden introducir errores en este módulo, pero podrían introducirse los mismos errores en las pruebas que lo probaron y dar como resultado una falsa sensación de seguridad de las pruebas que ya no funcionan según lo previsto. La conclusión es que las pruebas no son una solución mágica, son otra capa de protección, y esta pregunta discute el tema de si esta capa de protección vale la pena en el caso específico de un módulo que se demostró que es correcto (suponga que era de hecho).