TDD

Si alguna vez has oído a un programador hablar de «tests», «refactorizar» o «ciclos en rojo», probablemente no entiendas muy bien a qué se refieren.

Por eso, hoy vamos a explicarte de forma sencilla qué es el TDD en programación. Si te interesa saberlo, prepárate, porque vamos a desgranar este método paso a paso.

TDD: ¿Qué es y qué significa en informática?

El TDD (Test Driven Development), que en español conocemos como desarrollo basado en pruebas, es una metodología de programación que consiste en escribir primero las pruebas —los exámenes que debe pasar el código— antes de escribir la funcionalidad del programa en sí.

En lugar de crear una aplicación y luego comprobar si funciona, el TDD propone dar la vuelta a la tortilla: primero defines cómo quieres que se comporte el sistema y luego programas lo mínimo necesario para que eso ocurra.

Si te preguntas qué es el TDD en informática, piensa en un arquitecto que, antes de poner un solo ladrillo, diseña un sistema automático que comprueba si la estructura aguanta el peso. En el desarrollo de software, esto significa que el programador solo avanza cuando está seguro de que el camino es firme.

Si quieres saber qué significa TDD, nos encontramos con tres palabras clave: Test (Prueba), Driven (Guiado o Basado) y Development (Desarrollo). Es decir, es un desarrollo guiado por los exámenes que nosotros mismos le ponemos al código. Es una técnica que busca la excelencia, la limpieza y que el resultado final no dé sorpresas desagradables al usuario.

En resumen, el TDD no es más que una filosofía de trabajo. No se trata solo de encontrar errores, sino de diseñar mejor desde el principio.

¿Cómo funciona el ciclo TDD?

El TDD no es algo que se haga de vez en cuando, sino un ciclo repetitivo y constante. Los programadores lo llaman el «ciclo de las tres fases» o «ciclo rojo-verde-refactorizar». Es un proceso de tres pasos que se repite una y otra vez hasta que el programa está terminado.

Aquí te explicamos cómo funciona este proceso para que entiendas mejor qué es el TDD en su día a día:

1. Fase Roja (Falla):

   El primer paso es escribir una prueba para una pequeña función que aún no existe. Como la función no está escrita, la prueba va a fallar inevitablemente. En los programas de edición de código, esto se suele mostrar con una luz o un mensaje de color rojo.

   ¿Por qué es bueno que falle? Porque así confirmamos que la prueba realmente está comprobando algo y que no nos estamos engañando a nosotros mismos. Es el momento de decir: «Quiero que mi programa haga esto y, como aún no lo hace, el examen sale mal».

2. Fase Verde (Pasa):

   Ahora llega el momento de escribir el código. Pero, ojo, en el desarrollo basado en pruebas no escribimos todo el código de golpe. Solo escribimos la cantidad mínima de código necesaria para que la prueba que antes fallaba ahora pase.

   Cuando la prueba se pone en color verde, sentimos ese alivio de saber que esa pequeña pieza funciona. No buscamos que sea el código más bonito del mundo todavía, solo queremos que cumpla su misión.

3. Fase de Refactorización (Mejorar):

   Una vez que tenemos el color verde, es hora de limpiar. Refactorizar significa mejorar la estructura interna del código sin cambiar lo que hace. Es como si, después de cocinar un plato que sabe bien, limpiaras la cocina y ordenaras los ingredientes para que la próxima vez sea más fácil cocinar.

   Lo bueno es que, como ya tenemos la prueba en verde, podemos hacer cambios con la seguridad de que, si rompemos algo, la prueba volverá a ponerse roja para avisarnos.

Este ciclo se repite constantemente: se escribe una prueba pequeñita, se hace que pase, se limpia el código y vuelta a empezar. Así, paso a paso, se construye un programa robusto.

Ventajas de utilizar TDD

Muchos se preguntan si vale la pena perder tiempo escribiendo pruebas antes que el código. La respuesta corta es: sí, rotundamente. Los programadores usan TDD para estar más tranquilos.

Aquí tienes las principales ventajas para entender mejor qué es TDD en programación y aplicarlo:

1. Menos errores (bugs): Al probar cada pequeña pieza por separado, es mucho más difícil que se cuelen fallos graves. El software es más fiable.
2. Código más limpio: Como el TDD te obliga a pensar antes de escribir, el resultado suele ser un código más sencillo y fácil de leer para otros programadores.
3. Documentación viva: Las pruebas mismas sirven como manual de instrucciones. Si alguien quiere saber qué hace una función, solo tiene que leer la prueba asociada.
4. Ahorro de costes a largo plazo: Aunque al principio parece que vas más lento, te ahorras muchísimas horas de arreglar fallos cuando el programa ya está en manos de los usuarios.
5. Confianza total: Puedes hacer cambios grandes en tu aplicación sin miedo. Si algo deja de funcionar, las pruebas te avisarán al instante. Esto es vital para mantener la seguridad en internet, ya que un código bien probado es menos vulnerable a ataques.

Diferencia entre TDD y pruebas tradicionales

A veces se confunde el Test Driven Development con el simple hecho de «testear» o probar un programa. Pero hay una diferencia fundamental que tiene que ver con el «cuándo» y el «por qué».

En las pruebas tradicionales, el proceso es:

• Diseñas el programa.
• Escribes todo el código.
• Al final, intentas probar si funciona.
• Si falla, tienes que rebuscar entre miles de líneas de código para encontrar el error. Es como buscar una aguja en un pajar.

En el TDD, el proceso es justo al revés: el examen es el que guía el diseño. No escribes código a ciegas esperando que funcione, sino que construyes un algoritmo que ya nace con su propio sistema de verificación.

La diferencia es como la de alguien que construye un mueble siguiendo las instrucciones paso a paso y comprobando que cada tornillo encaja —TDD—, frente a alguien que monta todo el mueble a ojo y, al final, reza para que no le sobren piezas o no se tambalee —pruebas tradicionales—.

Ejemplo sencillo de TDD

Para que termines de comprender qué es el TDD en informática, vamos a imaginar que queremos crear una función muy simple: una que sume dos números.

1. Paso Rojo: Escribimos una prueba que diga: «Si le doy un 2 y un 3, el resultado debería ser 5». Como aún no hemos programado la función de sumar, el ordenador nos dirá: «Error, no encuentro la función de sumar». ¡Perfecto, estamos en rojo!
2. Paso Verde: Escribimos la función más simple posible: función sumar(a, b) { devolver a + b }. Ejecutamos la prueba y se pone en verde. El código hace lo que prometía.
3. Refactorizar: Miramos nuestro código. ¿Es legible? ¿Se puede simplificar? En una suma es difícil mejorar mucho, pero imaginemos que queremos cambiar el nombre de las variables para que sean más claras. Lo hacemos y volvemos a pasar la prueba para confirmar que sigue dando 5.

¿Ves qué fácil? Al final, el TDD no es más que aplicar el sentido común a la tecnología: asegúrate de que cada paso que das es firme antes de dar el siguiente.