Una de las prácticas más comunes en el desarrollo Ágil es TDD (Test Driven Development o Desarrollo dirigido por pruebas). TDD es un estilo para escribir software en el cual se utiliza las pruebas para el desarrollo de los requerimientos funcionales. Se escribe el set de pruebas antes de escribir el código de la aplicación, mejorando el entendimiento de lo que el código debe hacer.
Muchos programadores consideran que el beneficio primario es tener un buen set de pruebas. Sin embargo, cuando se realiza en forma correcta, TDD puede cambiar la forma en la cual diseña el software para mejor debido a que aplaza la decisión de diseño para el final. Debido a que no realiza las decisiones de diseño desde el inicio, puede estar abierto a mejores opciones de diseño.
Flujo de trabajo de TDD
Lo importante en TDD es la palabra Dirigido, lo cual indica que las pruebas dirigen el desarrollo de software.
El flujo de trabajo de TDD es:
- Escribir una prueba fallida
- Escribir código para hacer que pase la prueba
- Repetir los pasos 1 y 2
- Durante el proceso, re escribir el código agresivamente
- Cuando no pueda pensar en más pruebas, ha terminado
TDD vs. Pruebas al final
TDD insiste en que el desarrollo debe aparecer primero. Sólo cuando tenga su prueba escriba (y fallida) puede escribir el código para la prueba. Muchos programadores utilizan una variante escribiendo las pruebas en forma posterior, así primero escribe el código y luego las pruebas. En este caso, igual se realizan las pruebas, pero no obtiene los aspectos de diseño de TDD. Nada le impide escribir código no adecuado y luego invertir tiempo en escribir código para este código no adecuado. Escrito el código antes que las pruebas, uno tiene pre consideraciones de cómo el código debe funcionar, luego haces pruebas de esto. Con TDD se requiere de que el código haga lo contrario: escribir la prueba primero, y luego escribir el código para pasar la misma.
Posteriormente continuaremos revisando TDD con ejemplos, a fin de entender en forma más clara las ventajas. Les dejo algunas consultas: En su empresa ¿escriben pruebas para el código? ¿Utilizan TDD?¿Utilizan alguna metodología de pruebas diferente a TDD?
