Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido.
TDD fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y en esencia, es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero:
Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la prueba pase) y refactor. Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con prácticas de desarrollo ágil, TDD toma un enfoque mucho más amplio, y cambia su atención de las pruebas al diseño.
TDD está mucho más relacionado con el diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.
El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:
- El cliente escribe su historia de usuario.
- Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible.
- Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.
- Se comprueba que esta prueba falla.
- Se escribe el código que hace pasar la prueba.
- Se ejecutan todas las pruebas automatizadas.
- Se refactoriza y se limpia el código.
- Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando.
- Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.
Ventajas
Los programadores que utilizan el desarrollo guiado por pruebas en un proyecto virgen encuentran que en raras ocasiones tienen la necesidad de utilizar el depurador o debugger.
A pesar de los elevados requisitos iniciales de aplicar esta metodología, el desarrollo guiado por pruebas (TDD) puede proporcionar un gran valor añadido en la creación de software, produciendo aplicaciones de más calidad y en menos tiempo. Ofrece más que una simple validación del cumplimiento de los requisitos, también puede guiar el diseño de un programa. Centrándose en primer lugar en los casos de prueba uno debe imaginarse cómo los clientes utilizarán la funcionalidad (en este caso, los casos de prueba). Por lo tanto, al programador solo le importa la interfaz y no la implementación. Esta ventaja es similar al diseño por convenio pero se parece a él por los casos de prueba más que por las aserciones matemáticas.
El poder del TDD radica en la capacidad de avanzar en pequeños pasos cuando se necesita. Permite que un programador se centre en la tarea actual y la primera meta es, a menudo, hacer que la prueba pase. Inicialmente no se consideran los casos excepcionales y el manejo de errores. Estos, se implementan después de que se haya alcanzado la funcionalidad principal. Otra ventaja es que, cuando es utilizada correctamente, se asegura de que todo el código escrito está cubierto por una prueba. Esto puede dar al programador un mayor nivel de confianza en el código.
Desventajas
- Interfaces Gráfica de usuario (GUIs): aunque hay soluciones parciales propuestas.
- Objetos distribuidos: aunque los objetos simulados (MockObjects) pueden ayudar.
- Bases de datos: Hacer pruebas de código que trabaja con base de datos es complejo porque requiere poner en la base de datos unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba. Todo esto hace que la prueba sea costosa de codificar, aparte de tener disponible una base de datos que se pueda modificar libremente.
Análisis y modelación de sistemas de software 