TDD es una técnica propuesta en 2002 por Kent Beck (firmante del Manifiesto Ágil y autor de la metodología Extreme Programming) y altamente extendida desde entonces. Desarrollar atendiendo a esta técnica implica asumir que el código fuente incluye las pruebas unitarias, de tal forma que, no se puede considerar terminado un método/módulo si no existen las correspondientes pruebas que lo validan.
El algoritmo de esta técnica es bastante sencillo aunque el impacto en la forma de programar es muy alto por lo que para el programador es difícil interiorizar el proceso cuando se comienza a aplicar la técnica. El algoritmo consta de 3 partes:
1. Implementar la Prueba Unitaria que deberá cumplir el software que tenemos que construir. Si somos capaces de ejecutar la prueba (es muy posible que no llegue ni a compilar) la prueba no pasará.
2. Implementar el código mínimo necesario de negocio que hace que la prueba pase. Es importante destacar que el algoritmo propone que no busquemos el código óptimo en este momento (para eso está el último paso), únicamente nos interesa que la prueba pase (de ahí el nombre del método…el desarrollo lo dirigen las pruebas, nuestra meta principal es conseguir que las pruebas pasen, obviamente es crítico elegir bien el conjunto de pruebas necesarias para llegar a implementar el método/módulo/sistema que marcan las especificaciones).
3. Refactorizar el código escrito en el punto 2. La técnica de refactorización forma parte de la metodología Extreme Programming y se puede definir como alterar la estructura interna de un determinado código fuente sin alterar su comportamiento externo. Esta técnica obligatoriamente requiere para su aplicación de un robusto conjunto de pruebas automáticas que nos garantice que los pequeños cambios incorporados en el código no alteran su comportamiento. Las refactorizaciones se deben realizar siempre en pequeños y atómicos cambios.
La refactorización es un tema suficientemente extenso como para tratarlo por separado pero aplicado en un contexto de TDD nos deberemos centrar sobre todo en la robustez del código y en evitar el código duplicado generado en el paso 2. Cada pequeño cambio en el código implica que se vuelven a ejecutar las pruebas unitarias para verificar que no hemos “estropeado” nada con la refactorización.
Atendiendo a las interfaces gráficas de las herramientas de automatización de las pruebas unitarias se suele resumir el algoritmo de TDD con 3 palabras:
1. Rojo
2. Verde
3. Refactorizar
Rojo cuando se escribe la prueba se ejecuta por primera vez, obviamente no pasa y la interfaz la marca en rojo (en realidad lo que suele ocurrir es que rompemos la compilación...ni tan siquiera conseguimos el rojo). Verde cuando se escribe el código fuente que implementa el objeto de la prueba. Refactorizar…cuando mejoramos el código. Ojo, ese habitual olvidarse de este último paso, consiguiendo lo contrario de lo que pretende la técnica: un código de peor calidad.
Como se ha comentado anteriormente lo difícil de la prueba es ponerla en marcha, cambiar la forma de programar. M. Poppendieck asocia TDD al segundo principio de Lean Software Development: Build Quality-In, por su parte Henrik Kniberg comenta que sería lo último a lo que renunciaría en un equipo de desarrollo, M. Cohn le atribuye a una mejora significativa de la productividad de los equipos de desarrollo. Obviamente, las referencias (y sus promesas) son suficientemente solventes como para plantearnos el esfuerzo, pero hay que reconocer que nuestro primer acercamiento a TDD ha sido ciertamente "durillo". Probablemente por falta de experiencia en pruebas unitarias (+ mocks). Aunque no descartamos seguir profundizando e intentando su puesta en marcha, he de reconocer que la hemos postergado un poco en favor de otras prácticas más "ligeras" sobre las que podamos obtener un mayor ratio coste/beneficio.
Referencias utilizadas:
Diseño Ágil con TDD, Carlos Blé y colaboradores.
No hay comentarios:
Publicar un comentario