Por Benoît Faurie – TheExpert Digital Factory en Squad
¿Entonces todos tenemos más o menos claros los valores básicos deAgile?… Vale, ¿un repaso por si acaso?
Los cuatro valores que propone el manifiesto ágil son…
- Las personas y sus interacciones, más que los procesos y las herramientas
- Programas operativos, más que una documentación exhaustiva
- La colaboración con los clientes es más importante que la negociación contractual
- Adaptarse al cambio, más que seguir un plan
… y divididos en 12 principios que son… no, nos estamos desviando del tema.
¿Y qué hay del TDD y el BDD en todo esto?
En primer lugar, el TDD
El desarrollo basado en pruebas (o «Test -Driven Development», para los bilingües) es un método de desarrollo de software que consiste en escribir cada prueba antes de escribir el código fuente de un programa, de forma iterativa. El TDD se llamaba inicialmente «Test First Design», pero como la paciencia y el tiempo son más poderosos que la fuerza o la ira (esta es para ti, La Fontaine), el concepto básico evolucionó y se convirtió en el TDD. Este se basa en los tres valores siguientes:
- Debes escribir una prueba que falle antes de poder escribir el código de producción correspondiente
- Debes escribir una sola afirmación cada vez, que haga que la prueba falle o que falle la compilación
- Debes escribir el mínimo código de producción necesario para que se cumpla la afirmación de la prueba que actualmente falla
Bueno, ha sido un poco pesado, pero poco a poco lo vamos consiguiendo. Resumiendo, ¿qué es el TDD? Un método de desarrollo que permite crear software mejor diseñado, mejor probado (efectivamente) y más fiable. En resumen, mejoramos la calidad y cumplimos con los objetivos de Agile. ¡Genial! Ah, este enfoque se conoce como ATDD (Acceptance Test Driven Development).
La base de datos
El Behavior Driven Development es también un método de Gilles que fomenta la colaboración entre los participantes técnicos y no técnicos. Y aquí, cualquier desarrollador que me esté leyendo se dirá: «Sí, bueno, ya es complicado hacer entender a los no técnicos que no solo hago if/else, pero si además empiezan a meter mano, ¿cómo voy a trabajar yo? ». Ahí es donde reside la (casi) magia: de hecho, el BDD da prioridad al lenguaje natural y a las interacciones en el proceso de desarrollo de software.
Lo resumo así: el analista, el jefe de proyecto o tu jefe redacta, en un lenguaje (casi) natural, el objetivo y la utilidad del código. En realidad, se trata de especificaciones, y suelen seguir un formato similar al de las «historias de usuario».
Una solución: los pepinos están ricos, y los pepinillos también
¿¡¿Qué?!
Sí, porque, en realidad, trabajo sobre todo con tecnologíasLAMP/MEAN (bueno, aquí mejor que te dirija a Wikipedia, si no esto se va a alargar aún más) y, por eso, utilizo Cucumber (pepino en inglés) para mis desarrollos TDD. La ventaja de esta herramienta es que funciona tanto para proyectos en JavaScript como para proyectos en PHP.
Ya está, ahí lo tienes: Gherkin (pepinillo en inglés) se utiliza para las bases de datos y corresponde a la sintaxis que reconoce Cucumber para redactar la «especificación» de tu jefe.
Aquí tenéis un ejemplo y, para los más curiosos, os invito a echar un vistazo a la documentación: https://docs.cucumber.io/gherkin/reference/#feature
