Acceptance TDD: una práctica clave en equipos ágiles

¡Siglas y más siglas! Casi todos seguramente hemos escuchado alguna vez hablar de TDD, y posiblemente, algunos programadores apliquen esta gran práctica en su trabajo habitual. Pero, Acceptance TDD … ¿es otra cosa? ¿Por qué el nombre es parecido pero diferente?

Repasando brevemente, Test Driven Development (TDD) es una práctica que aplica el programador para guiar su flujo de trabajo. Una de las 2 reglas esenciales de TDD es que un programador no puede escribir código sin antes tener un test que falla. Entonces, primero escribe un test que no funciona y luego escribe el código necesario para hacerlo funcionar. Esta práctica, que en general resulta bastante anti-intuitiva y de costosa adopción, permite implementar una idea de diseño esencial: pensar en el QUE antes que en COMO.

En efecto, cuando primero escribimos un test, éste funciona como una especificación del comportamiento de la unidad de código que vamos a desarrollar. Entonces, tenemos claro cuál es el comportamiento esperado (QUE) desde el punto de vista de un primer cliente (el test) y luego procedemos a su implementación (COMO). No entraremos aquí en más detalles sobre TDD y sus ventajas (ver referencias). Sí observaremos que los tests automáticos constituyen, y se tratan, como una forma muy importante de documentación del código.

• Acceptance TDD (ATDD) es una práctica que aplica todo el equipo, cuyas características más destacadas son las siguientes:Comunicación y visión compartida. En vez de escribir requerimientos abstractos y detallados, en ATDD la funcionalidad se detalla mediante la escritura temprana de tests de aceptación. Se parte discutiendo y definiendo ejemplos concretos de comportamiento con el cliente, y luego, los ejemplos significativos se refinan y se agregan a los tests del sistema. Los ejemplos y los tests juegan un papel central en la comunicación del equipo y con el cliente para lograr entender qué es lo que hay que construir.
• Guiar del desarrollo: antes de empezar a programar, los programadores tienen y conocen los tests de aceptación. Estos tests son el objetivo a cumplir por los programadores. Durante el desarrollo, los ejemplos y tests se utilizan para resolver las dudas y ambigüedades que van presentando.
• Calidad en el Proceso. ATDD sirve para introducir la calidad en el proceso, a diferencia de que la calidad sea algo que se controle recién al final como en las metodologías más tradicionales. Ayuda a prevenir los bugs en vez solamente controlar que no haya bugs al final.
• ATDD y otras prácticas. La técnica de User Stories implica utilizar ATDD como forma de detallar los requerimientos. Sin embargo, ATDD también puede usarse con Casos de Uso. ATDD es una práctica que facilita que el equipo y el cliente tengan una visión compartida de lo que se va a construir. ATDD no implica la automatización de los tests funcionales, aunque esta automatización aporta muchas ventajas en un desarrollo ágil. Los tests, como en TDD, forman parte de la documentación del sistema. Para que los tests sirvan a su objetivo de comunicación, la automatización no puede realizarse con cualquier herramienta. Por ejemplo, Fitness es una gran herramienta para implementar ATDD pero otras herramientas no lo permiten.

Las metodologías ágiles nos plantean que todos los roles colaboren en pos de un objetivo común (entregar software valioso frecuentemente). Sin embargo, cuando se está empezando con agile, y cada rol sale de su “quinta o silo”, no es fácil ver cómo colaborar. ATDD aporta mucho en este sentido:

• Con ATDD, una parte importante de hacer análisis es definir ejemplos concretos de funcionamiento y los criterios de aceptación. Entonces, si hay un QA/tester en el equipo, éste participa en el análisis realizando estas tareas. O sea, que las actividades de análisis y testing se solapan y retro-alimentan desde el inicio del proyecto
• En sintonía con Agile, ATDD plantea que es responsabilidad de todo el equipo entender QUE tiene que hacer el sistema. Entonces, todo el equipo colabora en pensar y mantener los tests de aceptación.
• Los tests se escriben utilizando el lenguaje definido por Modelo de Dominio. Tener un modelo de dominio único y compartido por todo el equipo, es también una práctica ágil esencial que promueve la colaboración
• El foco temprano en los test y en los ejemplos concretos, genera posibilidades de trabajo en conjunto entre QA/testers y programadores para preparar los datos de prueba a utilizar en las distintas capas de la aplicación

Como muchas prácticas de Agile, ATDD le pide a cada rol ir un paso más allá de sus responsabilidades clásicas, y por esto, requiere nuevos skills y teamwork que no son sencillos. Sin duda, los beneficios que se obtienen ameritan la inversión y el esfuerzo! Entonces, para una mejor adopción, es recomendable tener en el equipo alguna persona que ya tenga experiencia en la práctica o contar con la guía y soporte de un mentor. Por otra parte, cuando se empieza con ATDD, se presentan muchas oportunidades de mejora que es importante que el equipo evalúe en sus retrospectivas.

Referencias
• Bridging the Communication Gap, Specification by Example and Agile Acceptance Testing. Una gran referencia sobre ATDD que abarca una descripción detallada de la práctica y herramientas asociadas. (ver más información en http://www.acceptancetesting.info/the-book/ )
• Sobre las ventajas de usar TDD: http://agilepainrelief.com/notesfromatooluser/2008/10/advantages-of-tdd.html