Los test de comportamiento nos permiten probar nuestro sistema en un nivel un poco más amplio. Mientras que los test unitarios nos dejan probar cosas puntuales, los de funcionamiento nos permiten probar casos de uso o user stories de manera integral.
Al tener una buena cobertura de nuestro sistema nos encontramos con que generamos lo siguiente:
- Confianza: sabemos que si algo sale mal los test nos lo van a hacer saber y podemos deshacer lo que haya salido mal.
- Refactor seguro: Sobre la base de la confianza ganada, podemos hacer casi cualquier refactor que se nos ocurra, sabemos que si los test dan bien no vamos a haber roto nada; y si aún así falla, estamos siempre a un rollback de distancia de la tranquilidad
- Nuevos features seguros: Otra ventaja que se desprende de la confianza es la posibilidad de generar nuevos features seguros, que no van a romper con el desarrollo previo, y si lo hacen, los tests darán la alarma y nuevamente podemos volver atrás con lo que falle
No es necesario que tengamos un proyecto realizado 100% con TDD y/o BDD, podemos generar test de comportamiento siguiendo ciertas premisas basicas de la metodologia SCRUM, sobre todo en lo que se refiere a las user stories
Las user stories son pequeñas y simples descripciones de caracteristicas del sistema explicadas en primera persona por quien desea la nueva funcionalidad. Generalemente siguen un patron comun:
Como <tipo de usuario>, quiero/necesito <funcionalidad esperada>, para <razon para la que solicita la funcionalidad>
Se suelen escribir en notitas adhesivas, y se distribuyen en paredes o tableros para poder visualizar, planear y discutir el curso a seguir para las características y/o funcionalidades.
Las user stories pueden abarcar desde un amplio aspecto de una gran funcionalidad hasta tareas mas especificas. A las grandes user stories se las refiere como epic (epicas). Como este tipo de user stories suelen ser muy grandes se suele subidividr en user stories mas pequeñas que pueden completarse en una iteracion del proceso de desarrollo.
Por ejemplo:
Como usuario, quiero copiar todo mi disco rigido (epic)
Esta epic user story se puede dividir en docenas de user stories mas pequeñas, como por ejemplo:
- Como usuario avanzado, quiero especificar que archivos copiar
- Como usuario, quiero indicar que archivos no copiar cuando el disco no este lleno
Para agregar detalle a las user stories, se pueden dividir en user stories mas pequeñas, se les puede agregar condiciones de realizado (Definicion de Hecho) Asi, como un poco mas de detalle tendriamos user stories de este tipo:
Como vice presidente de marketing, quiero evaluar una temporada de fiestas como reseña de la performance de campañas de publicidad anteriores, para poder indentificar las mas rentables
Como detalle extra podriamos agregar en la definicion:
Asegurarnos que funcione con la mayoría de las principales fiestas: Navidad, Pascuas, dia de la madre, del padre. Tomar hasta 2 años calendario
Esta metodología parece muy buena, pero ¿cómo implemento esto en mi proyecto? Para esto contamos con 2 herramientas, Gherkin y Cucumber
Gherkin, es un lenguaje comprensible, que vamos a usar para describir funcionalidades, definiendo el comportamiento del software, sin entrar en la implementación. Es fácil de leer y entender. Además nos permite crear la documentacion en conjunto con las pruebas de comportamiento. Más interesante aún, es que soporta varios idiomas ademas del inglés.
Para empezar basta con conocer 5 palabras basicas:
- Feature: Indica el nombre de la funcionalidad que vamos a probar. Debe ser un título claro y explícito. Incluímos aquí una descripción en forma de historia de usuario: “Como [rol ] quiero [ característica ] para que [los beneficios]”. Sobre esta descripción empezaremos a construir nuestros escenarios de prueba.
- Scenario: Describe cada escenario que vamos a probar.
- Given: Provee contexto para el escenario en que se va a ejecutar el test, tales como punto donde se ejecuta el test, o prerequisitos en los datos. Incluye los pasos necesarios para poner al sistema en el estado que se desea probar.
- When: Especifica el conjunto de acciones que lanzan el test. La interacción del usuario que acciona la funcionalidad que deseamos testear.
- Then: Especifica el resultado esperado en el test. Observamos los cambios en el sistema y vemos si son los deseados.
Así pasamos nuestras user stories a pruebas automatizadas, que podremos ejecutar con la ayuda de Cucumber
[...]
https://www.mountaingoatsoftware.com/agile/new-to-agile-or-scrum
https://www.mountaingoatsoftware.com/agile/user-stories