¿Qué es el TDD? - Tutorial de JavaScript

Test-Driven Development, o mejor conocido como TDD, no es más que el desarrollo de software basado en pruebas. Y esto es que primero tenemos que escribir una prueba y después tenemos que escribir el código. Pero antes de pasar a detalle a entender esta metodología debemos tener claro algunos conceptos. Por ejemplo, el qué es una prueba. Una prueba no es más que código para probar o validar código. Sí, un código que vaya a ejecutar tu código. Por ejemplo, si tienes una función de suma, tienes que escribir un código que invoque esa función de suma y pasarle algunos parámetros. Con esto nosotros vamos a poder entender cómo funciona nuestro código y verificar que, obviamente, los resultados de cada prueba van a ser los que estamos esperando. En este caso, si enviamos a una función de suma dos valores, el valor 2 y como segundo parámetro el valor 2, vamos a tener un resultado de 4. Entonces, sabemos qué resultado esperar. Una prueba, como lo indicamos, nos ayuda a entender nuestro código. Aquí la importancia es que nos van a ayudar a evitar muchos errores. Los errores, obviamente, detienen el trabajo y nos pueden causar una infinidad de problemas adicionales. Uno de los más importantes es que causan ciertos daños financieros, porque, obviamente, entre más tiempo te demores en resolver un problema, más tiempo te demoras en entregar y, por tanto, esto tiene un costo agregado. Esto, obviamente, va a mermar en la confianza con nuestros clientes, jefes y usuarios, así que nosotros debemos de tener bien claro que un código bien probado es igual a un proyecto bien entregado. Esto, obviamente, nos va a ayudar y nos va a causar más beneficios, que, obviamente, lo primero va a ser que va a incrementar la confianza con nuestros clientes, nuestros jefes y usuarios porque ellos, al notar que estamos entregando un producto estable y que funciona, nos van a poder consumir más o nos van a poder contratar más para resolver este tipo de problemas. Esto significa que si nuestro código en nuestro proyecto es confiable, por tanto, vamos a tener una estabilidad financiera o este puede incrementar, lo cual es muy benéfico. También, además de este tipo de beneficios, las pruebas nos van a permitir plantear bien nuestro código y van a agilizar el proceso de trabajo. Esto es que nosotros vamos a poder entenderlo y nos va a permitir jugar con las piezas de código en nuestra aplicación. A la vez, esto nos va a generar más confianza en nuestro código, así que cuando alguien venga a nuestro proyecto y nos diga ¡ey!, tu proyecto está fallando, nosotros tendremos tal certeza que podremos decir que no está fallando a causa de nuestra pieza de código, y esto es gracias a las pruebas. Por tanto, vamos a obtener un código limpio y estandarizado. Esto, obviamente, va a derivar en un beneficio adicional que es el tener una documentación. Esta documentación basada en las pruebas nos va a permitir que cuando venga algún programador adicional a nuestro proyecto, él podrá entender sin ningún problema cómo funciona nuestra aplicación. Y una cosa muy interesante que nos permiten las pruebas es que podemos descubrir puntos ciegos en nuestro código. A veces nos hace falta alguna validación o alguna asignación de datos que simplemente no consideramos al momento de escribir el código, al hacer una prueba vamos a poder descubrir estos puntos ciegos. Aquí vamos a entender cuatro puntos importantes. El primero es un cambio de paradigma. TDD cambia la forma en cómo escribes pruebas o en cómo escribes el código, lo cual nos lleva a que tenemos que identificar todas las posibles funcionalidades de nuestra aplicación. Pero una vez que las tienes identificadas es necesario que no escribas el código, puesto que primero debes de hacer la prueba, así tendremos una lista de pruebas que están fallando y después vamos a escribir el código para que estas pasen. Recuerda, si tu proyecto falla, no es porque hayas programado mal, es porque simplemente te hacen falta pruebas. Conforme vamos escribiendo nuestro códig somos propensos a tener fallos, pero a veces no nos damos cuenta de primera mano y hacer las pruebas nos ayuda a identificar cuál es el problema que tenemos con nuestro código. Pero ¡HOUSTON! ¡Tenemos un problema! Y esto es que requiere mucho tiempo y esfuerzo. Pero ¿por qué el tiempo y esfuerzo va a ser un problema? Bueno, aquí lo que te puedo decir es que la dedicación vale la pena. Sí, va a ser un problema porque escribir una prueba requiere tiempo, requiere esfuerzo, pero cuando lo hacemos, estas pruebas se vuelven nuestra red de seguridad y, al volverse nuestra red de seguridad, nos dan más confianza en nuestro código y podemos ganar rapidez al momento de escribirlas. Vas a encontrar muchas excusas y pretextos. Por ejemplo, oye, no hay tiempo, no escribas las pruebas, hay que entregar. O ¿sabes qué?, es que el retorno de inversión no es tan obvio. Aquí me refiero a que simplemente no es tan fácil demostrarle al usuario que es importante hacer pruebas y que necesitamos hacerlas o incluso a otros programadores. Otras excusas que puedes encontrar es que es imposible probar todo, pero lo que sí podemos hacer es tomar los elementos más importantes o críticos de nuestra aplicación y desde allí probarlos. Otro pretexto muy común es cuando te dicen ya, envíalo a producción, que trone lo que tenga que tronar. Y no es necesario que truene lo que tenga que tronar en el servidor, si tenemos pruebas, obviamente. Al principio, escribir pruebas requiere tiempo, pero puedes automatizar la ejecución de todas las pruebas. ¿Cómo? Cuando tienes piezas nuevas de código, ejecutas pruebas para ver que nada se rompa. Cuando subes al repositorio, cuando despliegas en servidores de desarrollo, de test o de producción o incluso cuando instalas una nueva librería. Así que automatizar las pruebas te va a ayudar muchísimo. Por tanto, una prueba es tu red de seguridad, nunca lo olvides. Así que, por favor, haz pruebas, esto va a garantizar que tu aplicación funcione sin ningún problema.