Quien ha utilizado el desarrollo orientado por las pruebas (TDD) sabe como está directamente relacionado con el diseño del código. Un diseño testeable (comprobable) normalmente es un diseño desacoplado y reutilizable. TDD es mucho más sobre diseño que sobre pruebas.
TDD es una práctica que envuelve el desarrollo en su conjunto. Especialmente el diseño. Algunos dicen que su última letra, la letra D, debería significar diseño y no desarrollo. Es decir, diseño orientado por las pruebas.
Me gusta especialmente esta idea. Es como tener un diseño ejecutable. TDD cuestiona al desarrollador frecuentemente sobre temas como con principio de responsabilidad unica (SRP) y no se repita (DRY). Trata las violaciónes de las prácticas de la orientación a objetos. Y ataca los puntos más humanos, simplificando el proyecto, donde se implementa sólo lo necesario (YAGNI).
Estos cuestionamientos son hechos a medida que sentimos menos dificultad en probar algo. ¿Por qué preciso depender de otro objeto para probar este sólo? ¿Será que ese método debería funcionar cuando es llamado por por sí mismo? ¿No era sólo un método de comando? Entonces, ¿por qué cambiar mi objeto?
TDD alienta a probar y verificar cada componente de software independiente. Esto hace al diseño emerger de forma extremadamente simple y poderosa. Simple para que cualquier futura modificación o mantenimiento sea rápido y fácil. Poderoso por la facilidad de extensión con un alto grado de seguridad. Como estamos trabajando con los test ejecutando la tarea de un consumidor final y directo, conseguimos alcanzar cohesión y bajo acoplamiento naturalmente. Paso a paso.
Sabemos que la calidad del diseño de un software está también relacionada con el conocimiento del equipo de desarrollo en relación al dominio en cuestión. Y TDD también es extremadamente influyente en este aspecto. Tener a las pruebas ejecutables como el primer ciclo de desarrollo, es lo minimo necesario lo que el desarrollador sepa lo que estará probando y dónde quiere llegar. Es él quien elaborará los criterios de aceptación.
Es imposible prácticar TDD sin refatorización constante. Y ese es el punto clave. El beneficio de los ciclos de refactorización es estar en todo momento centrado en el diseño. Cosa que no sucede en un flujo tradicional de desarrollo.
Se engaña aquel que indica que TDD no es productivo. Sino todo lo contrario. Por más que en un primer momento parezca improductivo, definitivamente no lo es. Al centrarse en el diseño y sólo en lo que es esencial ya estamos asegurando bajo desperdicio. Sin contar con que todo nuestro código está cubierto por pruebas, evitando las largas sesiones de depuración. Y, por supuesto, sin mencionar el diseño. Legible, flexible, simple, eficiente, cuidadoso... de fácil mantenimiento. ¿Querés algo más productivo? Aparte nos estamos acercando, naturalmente, a la idea de cero defectos. Y cuanto más defectos, más retrabajo.
Una gran serie de artículos escritos por Neal Ford, sobre arquitectura evolucionaria y diseño emergente, muestra en la práctica el impacto que TDD causa en el diseño de software.
Apostá tus fichas al desarrollo guiado por las pruebas y comprobá como el diseño de tu código emerge con calidad.
