Cuanto más tarde realice la prueba, más cuesta escribir las pruebas.
Cuanto más tiempo viva un error, más costoso es solucionarlo.
La ley de los rendimientos decrecientes garantiza que puedas ponerte a prueba y olvidarte de que no hay errores.
Buda enseñó la sabiduría del camino medio. Las pruebas son buenas. Hay tal cosa como algo demasiado bueno. La clave es saber cuándo está fuera de balance.
Cada línea de código que escriba sin pruebas tendrá costos significativamente mayores para agregar pruebas más tarde que si las hubiera escrito antes de escribir el código.
Cada línea de código sin pruebas será mucho más difícil de depurar o reescribir.
Cada prueba que escribas tomará tiempo.
Cada error llevará tiempo para solucionarlo.
Los fieles le dirán que no escriba una sola línea de código sin antes escribir una prueba fallida. La prueba asegura que está obteniendo el comportamiento que espera. Le permite cambiar el código rápidamente sin preocuparse por afectar el resto del sistema, ya que la prueba demuestra que el comportamiento es el mismo.
Debe comparar todo esto con el hecho de que las pruebas no agregan funciones. Código de producción añade características. Y las características son las que pagan las cuentas.
Hablando de manera pragmática, agrego todas las pruebas que puedo realizar. Ignoro los comentarios a favor de ver las pruebas. Ni siquiera confío en el código para hacer lo que creo que hace. Confío en las pruebas. Pero he sido conocido por tirar ocasionalmente el saludo y tener suerte.
Sin embargo, muchos codificadores exitosos no hacen TDD. Eso no significa que no prueben. Simplemente no insisten obsesivamente en que cada línea de código tenga una prueba automatizada contra ella. Incluso el tío Bob admite que no prueba su IU. También insiste en que muevas toda la lógica fuera de la interfaz de usuario.
Como metáfora del fútbol (que es el fútbol americano), TDD es un buen juego terrestre. Las pruebas manuales en las que escribes un montón de código y esperas que funcione es un juego de pases. Puedes ser bueno en cualquiera de los dos. Tu carrera no va a llegar a los playoffs a menos que puedas hacer ambas cosas. No hará la Superbowl hasta que aprendas cuándo elegir cada una. Pero si necesita un empujón en una dirección particular: las llamadas de los funcionarios van en contra de mí con más frecuencia cuando estoy pasando.
Si quieres probar TDD, te recomiendo que practiques antes de hacerlo en el trabajo. La TDD se realiza a medias, a medias y a medias es una razón importante por la que algunos no la respetan. Es como verter un vaso de agua en otro. Si no te comprometes y lo haces rápida y completamente, terminas regando agua por toda la mesa.