Introducción
En este artículo profundizaré en un concepto que considero importante dentro de nuestra práctica y que es lo relativo al testing funcional con BDD (Behavior Driven Development) y derivará al patrón Screenplay con un cierto nivel de profundidad. Estos enfoques no solo mejoran la calidad de nuestras pruebas, sino que también facilitan la comunicación y por ende, la colaboración entre equipos y aseguran que nuestros entregables tengan la calidad esperada y bajo la perspectiva del usuario final.
Vayamos al punto principal, ¿Qué es BDD?
BDD, o Behavior Driven Development, es una metodología que deriva del TDD (Test Driven Development), práctica que debe estar bajo el dominio del developer y en la que nosotros también podemos ayudar de alguna forma.
La idea principal que propone BDD es escribir pruebas que verifiquen que el comportamiento del código es correcto desde el punto de vista del negocio. En lugar de centrarnos únicamente en la funcionalidad técnica, BDD nos permite hablar en el lenguaje del negocio, lo que facilita la colaboración entre desarrolladores, testers y stakeholders, entre ellos principalmente el Product Owner.
Comparto un ejemplo Práctico:
Te propongo que imaginemos que estamos desarrollando una funcionalidad para un sitio de comercio electrónico donde los usuarios pueden agregar productos a su carrito de compras. Con BDD, escribiríamos escenarios de prueba en un lenguaje Gherkin.
Feature: Agregar productos al carrito de compras
Scenario: Usuario agrega un producto disponible al carrito
Given el usuario está en la página del producto
When el usuario hace clic en «Agregar al carrito»
Then el producto debe aparecer en el carrito de compras
And el carrito debe actualizarse con el nuevo total
Este texto debe registrarse y mantenerse en una herramienta que soporte este lenguaje y lo permita escalar a otras instancias, como puede ser la automatización del caso de prueba.
Algo no menor que me sucede muchas veces es atender las consultas de algunos testers que están acostumbrados a escribir sus casos de prueba en el formato tradicional y cuando se enfrentan con este tipo de escenarios, les cuesta “cambiar el chip”.
Herramientas de BDD
Las herramientas más comunes para implementar BDD incluyen:
- Cucumber (para Java y JavaScript)
- SpecFlow (para .NET)
- JBehave y Concordion
Estas herramientas permiten escribir pruebas en un formato Gherkin y ejecutarlas contra la aplicación.
Screenplay Pattern: Una Alternativa al Page Object
El patrón Screenplay es una evolución del patrón Page Object. Mientras que Page Object se centra en representar páginas web como objetos, Screenplay se centra en los actores y sus interacciones con el sistema. (artículo relacionado: Page Object)
Conceptos Clave de Screenplay:
- Actores: Representan a los usuarios que interactúan con el sistema.
- Tareas: Acciones que los actores realizan para alcanzar sus objetivos.
- Habilidades: Capacidades que los actores tienen y que les permiten realizar tareas específicas.
- Preguntas: Consultas sobre el estado del sistema que los actores pueden hacer.
Ejemplo Práctico con Screenplay:
Supongamos que queremos automatizar la misma funcionalidad de agregar productos al carrito de compras utilizando el patrón Screenplay (en Java).
public class AgregarProductoAlCarrito implements Task {
private final String producto;
public AgregarProductoAlCarrito(String producto) {
this.producto = producto;
}
public <T extends Actor> void performAs(T actor) {
actor.attemptsTo(
Open.browserOn().the(PaginaDelProducto.class),
Click.on(BotonDeAgregarAlCarrito.of(producto)),
Ensure.that(CantidadDeProductosEnCarrito).isEqualTo(1)
);
}
public static AgregarProductoAlCarrito conNombre(String producto) {
return new AgregarProductoAlCarrito(producto);
}
}
Aquí, AgregarProductoAlCarrito es una tarea que un actor (usuario) puede realizar. Utiliza habilidades como Open y Click para interactuar con la página y finalmente asegura que el producto fue agregado correctamente.
Algunas ventajas de usar el Patrón Screenplay
- Reduce los problemas de mantenimiento: Las pruebas son más fáciles de mantener ya que se centran en lo que los usuarios hacen en lugar de cómo se implementan las páginas.
- Pruebas más estables: La abstracción de las tareas y acciones hace que las pruebas sean menos propensas a romperse con cambios menores en la interfaz de usuario.
- Mayor legibilidad y mantenibilidad: Al separar claramente las responsabilidades, las pruebas se vuelven más fáciles de leer y entender.
Implementación Práctica y algunas recomendaciones
- Identifica a los Actores y sus Tareas: Comienza identificando quiénes son los usuarios de tu sistema y qué quieren lograr, para poder definir claramente las tareas y habilidades necesarias.
- Utiliza DSLs (Domain-Specific Languages): Con Gherkin podemos escribir escenarios en un lenguaje claro y comprensible, facilitando la colaboración y la comunicación dentro del equipo, principalmente el Product Owner, quién nos garantiza el enfoque que debe tener la funcionalidad a desarrollar (desarrollo propiamente dicho y el testing).
- Automatiza y Ejecuta regularmente: Integra tus pruebas BDD en tu pipeline de CI/CD para asegurarte de que se ejecuten automáticamente en cada cambio del código. Para lo cual deberás pensar en tener un Jenkins montado con sus correspondientes aplicaciones (herramientas) asociadas.
- Refactoriza constantemente: Así como se refactoriza el código de producción, también hay que hacer lo propio, es decir también hay que refactorizar nuestras pruebas para mantenerlas limpias, manejables, seguras y escalables.
Reflexión
Tanto BDD como el patrón Screenplay ofrecen enfoques para mejorar la calidad y eficiencia de nuestras pruebas funcionales. Al centrarse en el comportamiento del usuario y en la separación de responsabilidades, estos métodos no solo facilitan la colaboración y la comunicación dentro del equipo, sino que también producen pruebas más estables y mantenibles. Permiten algo muy importante, hacer participar al Product Owner.
