Cuanto más tarde realice la prueba, más le costará escribir pruebas.
Cuanto más dura un error, más costoso es arreglarlo.
La ley de rendimientos decrecientes asegura que pueda probarse a sí mismo en el olvido tratando de asegurarse de que no haya errores.
Buda enseñó la sabiduría del camino del medio. Las pruebas son buenas. Existe algo demasiado bueno. La clave es saber cuándo estás 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 hubiera escrito las pruebas antes de escribir el código.
Cada línea de código sin pruebas será significativamente más difícil de depurar o reescribir.
Cada examen que escriba llevará tiempo.
Cada error llevará tiempo para solucionarlo.
Los fieles le dirán que no escriba una sola línea de código sin primero escribir una prueba fallida. La prueba asegura que está obteniendo el comportamiento que espera. Le permite cambiar el código rápidamente sin preocuparse de afectar al resto del sistema, ya que la prueba demuestra que el comportamiento es el mismo.
Debe comparar todo eso con el hecho de que las pruebas no agregan características. El código de producción agrega características. Y las características son las que pagan las facturas.
Hablando pragmáticamente, agrego todas las pruebas que puedo hacer. 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 se me conoce por lanzar ocasionalmente el granizo de María 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 en su contra. Incluso el tío Bob admite que no prueba su interfaz de usuario. También insiste en que elimines toda la lógica de la interfaz de usuario.
Como metáfora del fútbol (eso es fútbol americano), TDD es un buen juego de tierra. Las pruebas manuales solo donde escribes un montón de código y esperas que funcionen son un juego de pasar. 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 formará el superbowl hasta que aprenda cuándo elegir cada uno. Pero si necesita un empujón en una dirección particular: las llamadas de los funcionarios van en mi contra más a menudo cuando paso.
Si desea probar TDD, le recomiendo que practique antes de intentar hacerlo en el trabajo. TDD hecho a la mitad, a medias y a medias es una gran razón por la que algunos no lo respetan. Es como verter un vaso de agua en otro. Si no te comprometes y lo haces rápida y completamente, terminas goteando agua por toda la mesa.
