TDD: Desarrollar a partir de pruebas

El desarrollo conducido por las pruebas o TDD (por sus siglas en inglés para Test Driven Development) por más que su nombre lo sugiera no es una técnica de testing. 

Es una técnica de diseño y desarrollo de software que propone un cambio de paradigma poniendo a las pruebas como pivote principal del proceso de desarrollo de software.

La idea es utilizar la capacidad de automatización de las pruebas (para esto existen varios frameworks que puedes aplicar) con varios objetivos como pueden ser:

• Comunicación: plasmar el entendimiento del problema en un lenguaje sin ambigüedad como es el código para diseñar los escenarios que sirvan como especificación de requisitos.
• Evidencia: generar una base de evidencia automática que nos permita mostrar como debe funcionar cada escenario previsto.
• Codificación: facilita generar el código estrictamente necesario para cumplir con la funcionalidad esperada. Eso sí, tiene la desventaja de que si el diseño de los casos no son completos puedes perder funcionalidad.
• Confianza: para encarar las mejoras la base de evidencia automatizada te dará la confianza que necesitas para realizar los cambios y mantener la seguridad de que todo continua funcionando.

Como todas estas técnicas, TDD tiene un ritmo. Depende del autor que leas habrá variación a continuación te dejo mi visión sobre los pasos que debes seguir para ejecutarla:

1. 1. Escribir una prueba que no pase: especificar el escenario a desarrollar.
2. 2. Escribir el código necesario para pasar la prueba.
3. 3. Verificar que se cumplen las condiciones del escenario especificado
4. 4. Refactorear: mejorar el comportamiento interno sin afectar el comportamiento observable.
5. 5. Volver al paso 1 y repetir hasta agotar la funcionalidad.

La agilidad no esta en el relajo, sino en la rapidez brindada por el ritmo de la metodología. Por lo tanto te sugiero que antes de empezar tengas un backlog priorizado que te permita decidir por donde empezar. Segundo que elijas cada funcionalidad y ejecutes el proceso hasta agotarla, y recién allí continúes con la siguiente. Aprovecha la etapa de refactorización para mejorar aspectos relacionados a la implementación o al diseño que puedan traerte problemas más adelante (ver post sobre deuda técnica) y así tender a un diseño simple.

No es una técnica infalible, porque como bien sabes no existe una solución 100% eficaz para todos los contextos pero es la base de varias de las metodologías ágiles y se continúa adoptando con muy buenos resultados.