TDD es una práctica de programación en el que primero se escriben las pruebas y después el código necesario para que funcionen.
La práctica consiste en crear la prueba, dejar que fallen, escribir el código para que funcione y al final re factorizar el código necesario.
El objetivo de esta práctica es tener un código más limpio y reutilizable y que los requisitos sean traducidos a pruebas, de tal modo que, al validar que todas las pruebas funcionan, se está cumpliendo con los requisitos.
Tradicionalmente en la construcción del software se diseña, se codifica y al final se prueba, por lo que se tiene un alto riesgo de olvidar probar todos los componentes del software, al utilizar TDD e iniciar con las pruebas se aprovecha para validar que el diseño este completo y no olvidemos algo importante, otro aspecto a favor de iniciar con las pruebas es que por parte de los ingenieros de software lo ven aburrido y al construir pruebas, estas no llevan la calidad necesaria, lo ven como un requisito que tienen que cumplir sin beneficio alguno.
Utilizando TDD con una metodología SCRUM, los pasos para realizar el software podrían quedar de la siguiente forma:
- Se analizan los criterios de aceptación.
- Por cada criterio de aceptación se genera una prueba unitaria.
- Validamos que la prueba falle.
- Realizamos la codificación necesaria para que la prueba falle.
- Validamos que la prueba no falle.
- Refactorizamos el código para hacerlo más limpio y legible.
- Validamos nuevamente la prueba.
Utilizar TDD nos ayuda a garantizar que lo que se está codificando va asociado a un requerimiento. Además, bajo esta forma de trabajo evitamos tener código que no se utiliza.
Las pruebas que se escriben son unitarias, ya que se busca comprobar el correcto funcionamiento de una función o procedimiento, estas pruebas unitarias se pueden automatizar para su ejecución y validación. Utilizando pruebas unitarias se puede automatizar su ejecución de tal modo que no necesariamente necesitamos conocer todo, ya que la automatización realizara la validación global y en caso de que falle algo podremos identificarlo de manera puntual.
TDD cuenta con una serie de retos, es difícil diseñar una solución cuando el requerimiento es muy ambiguo, así como las pruebas con interfaces gráficas complejas ya que dichas interfaces normalmente cambian durante el proceso de creación de la solución, por lo que los ajustes a las pruebas también serán frecuentes.
Si bien el test Driven Development es una práctica que presenta sus propios retos; también es una gran opción para escribir código más limpio y eficiente.
