Metodología de pruebas bastante extendida cuyo acrónimo significa:

• Inglés: Test Driven Development.
• Español: Desarrollo guiado por pruebas.

Se utiliza generalmente para el desarrollo de pruebas unitarias y no es dependiente de ningún lenguaje. El proceso de desarrollo siguiendo esta metodología se compone de tres etapas diferentes:

1. Se escriben las pruebas y se comprueba que fallan.
2. Se implementa el mínimo código que hace que las pruebas se pasen exitosamente.
3. Se refactoriza el código escrito.

La idea de la metodología es que los requisitos de negocio sean transformados en pruebas asegurando de este modo que al final el desarrollo, todos los requisitos se cumplen. También es evidente que utilizando esta metodología, otro de los objetivos que se alcanzan es el de tener una amplia cobertura de pruebas en nuestros proyectos, ya que nunca se va a desarrollar nada para lo que no se hayan escrito sus pruebas previamente. Esto deriva en que en las siguientes iteraciones del proyecto, el desarrollador que quiere introducir nuevos cambios puede confiar en que el código que va a modificar o va a utilizar en su desarrollo funciona e implementa de forma correcta los requisitos de negocio.

A la hora de la implementación, se pretende que el código siga dos principios básicos y ampiamente conocidos como son:

• KISS: “keep is simple stupid”. Literalemnte traducido por “Mantenlo sencillo estupido”, aunque prefiero la traducción “Mantenlo estúpidamente sencillo”. Que nos viene a instar a mantener nuestros sistemas lo más simples posibles a través de buenas prácticas de diseño.
• YAGNI: “You aren´t gonna need it”. Literalmente traducido por “No lo vas a necesitar”. Este principio nos insta a no implementar cosas que no se van a utilizar, ni siquiera aunque pensemos que en un futuro quizás lo vayamos a hacer, porque en la mayoría de las ocasiones, ese futuro nunca llega.

Pero bueno, después de toda esta introducción teórica, vamos a implementar algo.

Primera Fase: Escribir las pruebas y comprobar que fallan.

public interface Calculator {
    int add(int a, int b);
    int subs(int a, int b);
    ....
}

public class MyCalculator implements Calculator {
    public int add(int a, int b) {
        return 0;
    }

    public int subs(int a, int b) {
        return 0;
    }

    ...
}

public class MyCalculatorTest {

    Calculator calc;

    @Before
    public void setUp() {
        calc = new MyCalculator();
    }

    @Test
    public void addTest() {
        assertEquals(2, calc.add(1, 1));
    }

    @Test
    public void subsTest() {
        assertEquals(1, calc.subs(2, 1));
    }

    ...
}

Segunda Fase: Implementar el mínimo código

public class MyCalculator implements Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public int subs(int a, int b) {
        return a - b;
    }

    ...
}

Tercera fase: Refactorizar nuestro código

En este caso, está tercera fase obviamente no tiene mucho sentido ya que el código se ha hecho lo más simple posible para que nos fijemos solo en el proceso de TDD y no en el código. Pero por si alguno no está familiarizado con el término refactorizar, os dejo el enlace de su definición: Refactorización

Tras esto tendríamos listo nuestro código con nuestras pruebas y la implementación de nuestra lógica de negocio, con lo que podríamos pasar al siguiente requisito.

Se que es una pequeña (muy pequeña) introducción al término de TDD pero creo que puede ser útil para aquellos que lo desconozcan o nunca lo hayan utilizado. Nos vemos.