Como realizar testing automatizado en Outsystems. Ciclo OutSytems IV

En este artículo hablaremos de uno de los aspectos relevantes durante el proceso de el desarrollo, el testing y como automatizar el testing unitario en Outsystems.

Outsystems es una plataforma low code que proporciona herramientas para que las compañías desarrollen y gestionen aplicaciones empresariales omni canal. La plataforma integra las herramientas y capacidades de CI/CD, integrando las prácticas de desarrollo Agile Out-of-the-Box.

Dentro del ciclo de desarrollo, uno de los principales retos es tener una buena estrategia de testing que permita asegurar la calidad de las soluciones entregadas así como la robustez de futuros cambios y evoluciones en los diferentes componentes y módulos desarrollados.

La estrategia del testing

Una de las estrategias de testing más extendida en los procesos de desarrollo se basa en la “Test Pyramid” que agrupa los diferentes tipos de tests en base a la granularidad e integración con otros componentes, y que va directamente relacionado con la complejidad y mantenibilidad de los mismos (así como su velocidad de ejecución y coste de automatización).

Test Pyramid

 

Acorde a este modelo, los tests de componentes, situados en la base, son más fáciles de automatizar y mantener que los situados en las capas superiores, incrementando el coste de automatización y de mantenimiento a medida que se asciende a la parte superior de la pirámide.

Una de las claves para poner en práctica una buena estrategia de testing es desarrollar las aplicaciones de forma testable y en este punto seguir las best-practices de la Arquitectura de 4 Capas de Ousystems es clave para poder distribuir funcionalidades correctamente segregadas y testeables.

La automatización de los tests

Una de la claves a la hora de definir e implantar una estrategia de testing es la automatización de los mismos.

Al tener un conjunto de tests automatizados y robustos estos pueden ser integrados en el ciclo de desarrollo de forma fácil, asegurando su ejecución de forma continua y desatendida e incrementando la calidad y robustez de la solución desarrollada.

Un buen conjunto de tests es clave para asegurar que futuras evoluciones de las funcionalidades entregadas no rompen comportamientos de componentes o módulos ya existen, reduciendo impactos en entornos posteriores al de desarrollo (preproducción, producción).

La ejecución de los tests en fases tempranas del ciclo de desarrollo permiten anticipar al máximo efectos colaterales o comportamientos no deseados sobre todo en arquitecturas de aplicaciones complejas donde tenemos módulos que con funcionalidades reutilizadas por otros módulos.

Digital Lover

¿Por dónde empezar?

En Outsystems, los candidatos ideales para iniciar la automatización del testing consisten en los test de componentes. Para ello, se puede utilizar el BBFramework, disponible en la Forja de Outsystems.

Este pluguin proporciona toda una seria de herramientas para la creación y ejecución de tests bajo el paradigma del “Behaviour Driven Development” (o BDD) por el cual, se especifican los tests en base al comportamiento esperado, utilizando lenguaje “Gherkin”:

 

Scenario: Adding a product to the cart

Given:
That I have a cart
And there is a product called “Prosecco Armani DOC”

When:
I add the product to the cart

Then:
The operation should be successful
And the cart should have been correctly updated
  • Scenario: describe una situación en base a reglas de negocio
  • Given: define el contexto previo existente para ejecutar el test
  • When: describe la acción/evento que se produce
  • Then: describe el resultado esperado una vez realizada la acción/evento en el sistema.

Como crear un título con BDD Framerwork

En un inicio, lo primero a realizar es la descargar BDD Framework de la forja.

BDDFramework

Es recomendable, para cada aplicación a testear, crear un aplicación que encapsule los tests, de forma que se mantengan de forma las dependencias con BDDFramework, además de poder realizar la puesta en producción de la aplicación sin los test incluidos (Bad Practice del testing):

Sobre esta aplicación de test, se incorporan las dependencias a BDDFramework, teniendo como resultado la siguiente arquitectura de la aplicación:

OutSystems Platform

 

Una vez incorporadas las dependencias, BDD Framework proporciona diferentes web blocks para cada una de las estructuras necesarias en el escenario.

Blocks BDDFramework

Para cada escenario se utiliza la UI Screen de BDDFramework que permite modelizar el test concreto, implementando los diferentes BDDSteps como Server Action.

UI Screen de BDDFramework

 

Para ejecución de los test existen dos vías:

  • De forma manual, mediante la abertura de la Web Screen de la aplicación de Tests
  • Integrando en proceso de CI/CD con una llamada api en el siguiente formato:
rest/v1/BDDTestRunner/{TestESpace}/{TestSuiteScreen}

Esta llamada retorna un JSON que puede ser procesado por la pipeline de CI/CD de forma que se pueda alertar, parar el proceso de despliegue, reintentar en base a las políticas de CI/CD definidas.

Conclusiones

La estrategia del testing y el foco en la automatización de los tests es una herramienta imprescindible para asegurar la calidad del código desarrollado así como posibles impactos negativos de nuevos desarrollos sobre funcionalidades ya existentes.

En Outsystems existen mecanismos y pluguins que permiten integrar en el proceso de CI/CD los test necesarios para dotar de mayor robustez a las soluciones sin perder el foco del desarrollo ágil ni el aporte de valor por entrega de funcionalidad de forma iterativa e incremental.

Os recomiendo a todos a incorporar este pluguin y las técnicas asociadas al mismo en los desarrollos con tal de asegurar mayor calidad y robustez a las soluciones.

 

 

Tags

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA