TDD (Test Driven Development). Desarrollo dirigido por pruebas

Test Driven Development (TDD), o desarrollo dirigido por test en castellano, es una técnica de ingeniería de software para diseñar software.

Miguel A. Gómez · Seguir2 min read ·

Test Driven Development (TDD), o desarrollo dirigido por pruebas en castellano, es una técnica de ingeniería de software para, valga la redundancia, diseñar software. Como su propio nombre indica, esta técnica dirige el desarrollo de un producto a través de ir escribiendo pruebas, generalmente unitarias.

El TDD fue desarrollada por Kent Beck a finales de la década de los 90 y forma parte de la metodología extreme programming. Su autor y los seguidores del TDD aseguran que con esta técnica se consigue un código más tolerante al cambio, robusto, seguro, más barato de mantener e, incluso, una vez que te acostumbras a aplicarlo, promete una mayor velocidad a la hora de desarrollar

Las tres leyes del TDD

Robert C. Martin describe la esencia del TDD como un proceso que atiende a las siguientes tres reglas:

• No escribirás código de producción sin antes escribir un test que falle.
• No escribirás más de un test unitario suficiente para fallar (y no compilar es fallar)
• No escribirás más código del necesario para hacer pasar el test.

Estas tres leyes derivan en la repetición de lo que se conoce como el ciclo Red-GreenRefactor. Veamos en qué consiste:

El ciclo Red-Green-Refactor

El ciclo Red-Green-Refactor, también conocido como algoritmo del TDD, se basa en:

• Red: Escribir un test que falle, es decir, tenemos que realizar el test antes de escribir la implementación. Normalmente se suelen utilizar test unitarios, aunque en algunos contextos puede tener sentido hacer TDD con test de integración
• Green: Una vez creado el test que falla, implementaremos el mínimo código necesario para que el test pase.
• Refactor: Por último, tras conseguir que nuestro código pase el test, debemos examinarlo para ver si hay alguna mejora que podamos realizar.
• Una vez que hemos cerrado el ciclo, empezamos de nuevo con el siguiente requisito.

Esta forma de programar ofrece dos beneficios principales. El primero y más obvio es que obtenemos un código con una buena cobertura de test, lo que es positivo hasta cierto punto. Recuerda, nos pagan por escribir código que funciona, no por hacer test.

El segundo beneficio es que escribir primero las pruebas nos ayuda a diseñar la API que va a tener nuestro componente, ya que nos obliga a pensar en cómo queremos utilizarlo. Esto suele acabar derivando en componentes con responsabilidades bien definidas y bajo acoplamiento.