TDD Metodologias Agiles

TDD

Desarrollo dirigido por pruebas (test) es una técnica de desarrollo e implementación de software incluida dentro de la metodología XP (programación extrema). Tiene 3 pilares fundamentales:

1. Implementar solo los requerimientos que el cliente necesita, nada más.

2. Hacer todo lo posible para minimizar los defectos del software en la fase de producción

3. Producir un software muy flexible ante los cambios de requerimientos del cliente.

Antes se pensaba que los CU eran las unidades más pequeñas, con TDD se cambia la idea de CU a tarea con N ejemplos, de esta forma se entenderá muy bien la tarea sin lugar a malentendidos.

En las metodologías normales se estudia y se establece a priori cual es la infraestructura de cada caso, esto depende de lo otro, esto es el mas importante. ¿Qué sucede si mientras se desarrolla nos damos cuenta que esto no funciona asi (casi siempre ocurre)? ¿Cuándo dinero se habrá malgastado? En TDD dejamos que la implementación de pequeños ejemplos, en varias iteraciones, vallan formando poco a poco cual es la arquitectura que necesitamos usar.

Beneficios de usar TDD como herramienta de diseño principal:

- La calidad del software aumenta.

- Se consigue código altamente reusable

- Multiplica la comunicación entre miembros del equipo

- El escribir el ejemplo (test) antes que el código nos obliga a escribir el mínimo de funcionalidades necesarias, evitando rediseñar.

- Nos hace descubrir más casos de uso en pleno desarrollo sin causar impacto.

Algoritmo TDD

- Hacer la especificación del (test, ejemplo):

¿Cómo escribimos un test para un código que no existe? Respondamos esto con ¿Acaso no es posible escribir una especificación antes de implementarla? El test es inicialmente un ejemplo o especificación. Si queremos cómo será el API de algo debemos trazar antes de implementar, pero solo una parte pequeña bien definido y comprobar que haga algo que queremos que haga.

- Implementar el código que hace funcionar el ejemplo

Teniendo el ejemplo escrito codificamos lo mínimo necesario para que el test pase. No importa que el código se a feo ya que en las siguientes iteraciones se corregirá, pero tampoco quiere decir que escribamos sin pensar, debemos concentrarnos en codificar solo lo que nos piden. En ese momento nos vendrán dudas de cómo funciona los distintos flujos condicionales. Se deben apuntar estas dudas para solucionarlo poco a poco en las siguientes iteraciones.

- Refactorizar para hacer mejoras y eliminar duplicidad

Refactorizar no quiere decir reescribir el código. Refactorizar es modificar el diseño sin cambiar el comportamiento. En este tercer paso rastreamos el código en busca de líneas duplicadas y las eliminamos refactorizando y se verifica que su método en cuestión y su clase

...