Es nuestro amigo porque:
Podemos escribir tests mantenibles y flexibles.
Tiene un reporte comprensible.
Podemos ajustar las pruebas a nuestros requisitos.
Controlamos el progreso y calidad del proyecto.
Hacia una Automatización Robusta con Beneficios y Prácticas Clave Usando Serenity BDD
Me gusta Serenity BDD por el hecho de ser una librería que nos permite realizar pruebas automatizadas de una manera sencilla, robusta y rápida.
Motivación
Aplicar buenas prácticas para el desarrollo de pruebas automatizadas permite mantener un proyecto que evoluciona rapidamente e influye a la imagen de la empresa.
Diagrama de arquitectura
En nuestro gráfico vemos la necesidad de crear una API PARA DATOS separada de Serenity BDD buscando desacoplar toda la lógica que será enteramente para el testing. Además y es lo que más me gusta, tener la posibilidad de utilizar esta Api para otros proyectos de testing de la empresa como la versión de App movil del producto testeado.
Nuestra Api
Para la construcción de la Api Rest decidí usar Java con Spring Boot por el hecho de que es el Stack de la empresa para la que realicé el proyecto. Si quieremos hablar un poco de la arquitectura, usé las especificaciones de Clean Architecture:
Cómo lo organizamos:
config: Todo lo referente a configuración del framework por ejemplo: CORS o datos del application.properties.
controller: Recibimos las peticiones del cliente por ejemplo: obtener lista de productos.
exception: Tenemos un ExceptionHandler para personalizar errores al cliente, obtener logs y dar detalles.
integration: Es nuestra comunicación con Apis externas y conexiones a bases de datos.
repository: Contiene lógica para transformar datos para la capa de integracion y seleccionar información relevantes para la capa de dominio (directorio service).
entities: Clases que serán parte de nuestra lógica de negocio por ejemplo: productos.
service: Es el dominio de nuestro sistema, aquí se conectan las entities y colocamos validaciones. Este directorio se conecta al resto (repository, controller) a través de interfaces por lo que desconoce su implementación.
shared: Es lógica podemos utilizar en todo el software.
Nuestras pruebas automatizadas
Para las pruebas automatizadas usamos cucumber junto a Srenity BDD con la inclusión de JUnit y Selenium.
Cómo lo organizamos:
integration: Es la que conecta nuestras pruebas automatizadas con el Api descrito anteriormente.
models: Tranquilamente puede ser nuestro Entities (captura anterior) y aquí guardamos nuestras entidades del negocio.
pageobjects: Son constantes, o referencias en XPATH específicos de una página dentro del flujo.
questions: Son puntos de validación dentro de nuestras pruebas, por ejemplo: ¿Mostró el valor de $15?.
starter: Aquí se alojan nuestros banco de pruebas.
stepdefinitions: Son las definiciones del texto escrito en lenguaje Gherkin (Cucumber), en otras palabras, es nuetro traductor a código.
tasks: Son tareas que vamos a realizar dentro de nuestras pruebas automatizadas. Por ejemplo, inciar sesión o llenar un formulario.
resources/features: Es la característica que queremos probar en lenguaje Gherkin gracias a Cucumber. Por ejemplo enviar un mensaje a un contacto nuevo.
resources/images: Son todos los recursos en imágenes que usaremos dentro del proyecto.
¿Cómo podemos integrar ambos mundos?
Podemos integrarlos desde un ambiente local ejecutando Api Rest y luego arrancar el test automatizado que preferimos. Otras alternativas, un poco más avanzadas, es usar Docker para levantar ambos servicios y ejecutarlos.
Así mismo, podemos usar un servidor de integración continua como Jenkins para ejecutar nuestras pruebas automatizadas y obtener reporte de calidad para nuestros líderes.
Conclusiones
Para serles sincero, cuando inicié mi carrera en el campo del desarrollo de software, me centraba en el código, llevar buenas prácticas de programación, respetar arquitecturas y patrones de diseño, etc. Sin embargo, con el tiempo me di cuenta que la codificación no lo es todo y que por más que nos centremos en las mejores prácticas; siempre estamos propensos a un bug inesperado, un error del desarrollador, un cambio de requerimiento que se lo hizo de último momento y resultó en un fallo que salió a producción, etc.
Obviamente, me gustaría indicar que en todos los equipos en los que he trabajado, implementábamos correctamente el ciclo de desarrollo del software pero el mundo no es ideal y siempre buscábamos herramientas para entregar productos de calidad porque surgian incovenientes, nunca devastadoras, pero ocurrian.
Por ello, implementar herramientas para realizar pruebas automatizadas, es una excelente opción para probar aquellos componentes críticos de nuestro sistema cuyas pruebas son rutinarias y repetitivas.