Un marco de pruebas automatizado usando ProcessMaker + Selenio + Github
En la actual era moderna de construcción de software, todos los equipos de desarrollo de software bien gestionados deberían entender el valor de las pruebas. Las nuevas aplicaciones deben ser construidas con una cobertura de prueba unitaria casi perfecta para las pruebas automatizadas. Además, las pruebas funcionales basadas en navegadores deberían ser totalmente automatizadas usando herramientas de código abierto como el Selenio para capturar patrones conocidos de interacción humana.
Los desafíos de la incorporación de pruebas funcionales en la IC/CD
Los casos de uso funcional tienden a evolucionar a lo largo del tiempo y cambian regularmente a medida que los casos de uso de un conjunto de programas informáticos crecen y evolucionan. Como resultado, muchas empresas luchan con la forma de ejecutar un conjunto de pruebas de selenio en constante evolución como parte de un proceso automatizado de prueba y despliegue.
En particular, en el mundo actual del software SaaS, muchas aplicaciones SaaS para múltiples arrendatarios tienen suites enteras de pruebas de selenio que deben ejecutarse antes de abastecer a un nuevo arrendatario. Estas pruebas deben ejecutarse como parte del proceso automatizado de aprovisionamiento del arrendatario real.
La realidad, sin embargo, es que la mayoría de las empresas de SaaS no lo hacen. El resultado se muestra como constantes inconsistencias durante el aprovisionamiento de nubes privadas o de inquilinos.
Entonces, ¿cuál es la solución?
Aunque el selenio es una forma efectiva y popular de automatizar las pruebas basadas en el navegador, las organizaciones necesitan una forma de automatizar la inclusión de cubos de prueba de selenio debidamente versionados en las tuberías de despliegue.
ProcessMaker es una solución ideal para automatizar el despliegue y el aprovisionamiento de pruebas de selenio directamente desde sus depósitos en Github. Veamos cómo se puede hacer esto.
Suites de prueba de selenio en Github
Imagina por un momento una compañía que tiene un cubo de pruebas automatizadas de Selenio que se almacenan como archivos Python en GitHub. Estos archivos Python deben ser ejecutados cada vez antes de que un nuevo inquilino del espacio de trabajo o una instalación de nube privada sea aprovisionada. Si alguna de las pruebas falla, queremos asegurarnos de que el aprovisionamiento no siga adelante.
Además, reconocemos que los casos de prueba estarán en constante cambio y evolución. En este caso, tenemos múltiples equipos que quieren ser capaces de contribuir con pruebas a un repositorio versionado, y queremos estar seguros de que nuestras pruebas de selenio se ejecutan siempre utilizando la última versión estable y aprobada de las pruebas.
En este caso, las pruebas se harán con Selenio. Por supuesto, el Selenio es una herramienta de código abierto extremadamente popular que es utilizada por desarrolladores de todo el mundo. Con Selenio, puede automatizar cada tarea en su navegador. Además, es compatible con Chrome, Firefox, Safari, IE y Mozilla.
En ProcessMaker hemos creado un flujo de trabajo de despliegue que saca el arnés de prueba de selenio apropiado de github, lo ejecuta, comprueba si hay problemas, y si todo pasa, entonces llama a una función Lambda para desplegar un nuevo servidor AWS con el código verificado.
ProcessMaker nos da una representación visual del flujo de trabajo, una capacidad de rastrear el rendimiento, el tiempo y los errores. Esto es lo que el flujo de trabajo se ve para una empresa que actualmente utiliza ProcessMaker de esta manera:
La flexibilidad es clave para la gestión de las pruebas. ProcessMaker facilita la reagrupación y refactorización de los casos de prueba para que se pueda mejorar la mantenibilidad mientras se disminuye la complejidad y la duplicación. Con las herramientas fáciles de usar de ProcessMaker, usted puede reducir el tiempo de ejecución de las pruebas e incluso ejecutar varias pruebas en paralelo.
Usando ProcessMaker, las pruebas de selenio se extraen del repositorio de código y se ejecutan a través de una serie de tareas de guión en ProcessMaker que canaliza la prueba a través de una imagen de Selenium Docker y luego almacena los resultados de la prueba en la solicitud.
Parte de la belleza de ProcessMaker es que maneja los datos como un objeto Json muy ligero, desestructurado y fácil de entender. Durante la vida de una solicitud (una instancia de proceso), este Json puede recibir datos de muchas fuentes diferentes. En el caso de las pruebas de Selenio, los resultados que se devuelven de las pruebas de Selenio simplemente se añaden al objeto Json. Entonces, dependiendo de cómo se supone que funciona nuestro flujo de trabajo, podemos usar reglas externas o pasarelas para evaluar los resultados y cambiar lo que ocurre en el flujo de trabajo.
Para ilustrarlo, ProcessMaker puede ser configurado para ejecutar acciones de seguimiento basadas en los resultados de las pruebas que devuelven resultados == "éxito". En la puerta de enlace, evaluamos la variable de los resultados. Si los resultados fueron exitosos, entonces hemos configurado el flujo de trabajo para llamar a una nueva prueba de guión que es la función lambda que usamos para hacer girar un nuevo inquilino (espacio de trabajo). Si los resultados muestran "fracaso" entonces no seguiríamos adelante con la rotación del inquilino. En ese caso, podríamos querer publicar los detalles del fallo en un canal de Slack o a través de un correo electrónico utilizando los conectores de ProcessMaker para Slack o para el correo electrónico.
Usando ProcessMaker como un arnés de prueba de esta manera, podemos probar cualquier aplicación personalizada antes de implementarla en un servidor para un cliente. Obtenemos flexibilidad en flujos de trabajo complejos y la capacidad de escalar y disparar pruebas a pedido.
Ejecución del proceso a través de la API de ProcessMaker
Debido a que la ejecución del proceso puede ocurrir a través de llamadas a la API, el uso de ProcessMaker puede formar parte de sus tuberías de CI/CD. Si se despliega o actualiza un entorno, el conducto de CI/CD puede ejecutar una llamada a la API REST contra ProcessMaker para comenzar a ejecutar un conjunto de pruebas basado en la carga de la solicitud de llamada a la API.
Usando un proceso de CI/CD se obtienen cierres más rápidos de los problemas porque se identifican y corrigen más rápidamente los errores. Además, la planificación y ejecución de las pruebas se mantiene de forma consistente. No se requieren habilidades técnicas. El despliegue es más fácil y rápido, casi sin tiempo de inactividad. Se pueden crear aplicaciones de mayor calidad porque se dispone de más tiempo para centrarse en las pruebas de usabilidad, seguridad, exploración y rendimiento. La retroalimentación continua también mejora la calidad general.
Ejecución del sub-proceso
Se puede diseñar un proceso simple para ejecutar una sola prueba de selenio y devolver el resultado. Un conjunto de pruebas puede ser un proceso padre que se repite a través de la ejecución de un conjunto de pruebas definido y realiza decisiones de flujo de trabajo más complejas basadas en los resultados.
En su esencia, el motor de flujo de trabajo ProcessMaker es altamente personalizable. Puede realizar un seguimiento de las pruebas con total transparencia. Algunas de las ventajas son las siguientes:
- Mejor eficiencia de la prueba
- Disminución de los costos de mantenimiento
- Cobertura de pruebas optimizada
- Se necesita poca intervención manual
- Reutilización del código
- No es necesario tener experiencia en automatización de pruebas
Pruebas basadas en el selenio en contenedores con tareas de guión
Las tareas de guión se ejecutan en contenedores Docker durante el ciclo de vida de ese guión. Podemos aprovechar la imagen de los contenedores de Selenio para ejecutar una prueba con aislamiento en caja de arena. También podemos personalizar la imagen acoplada para heredarla de la imagen base de selenio y luego proporcionar un andamiaje para cargar la prueba y ejecutarla que devuelva los resultados en un formato JSON adecuado que ProcessMaker espera.
¿Por qué a ProcessMaker le gusta JSON? Bueno, para empezar, JSON es más legible y compacto que XML, lo que facilita el trabajo con sistemas complejos. Como JSON usa menos datos que XML, el análisis sintáctico del software es mucho más rápido. JSON también facilita el mapeo de tiempo para dominar los objetos. La estructura de datos del mapa de JSON también es fácil de entender. Además, JSON asegura la coincidencia de objetos y códigos.
Escalado
La ejecución de las suites de pruebas se realiza a pedido y puede configurarse como un despliegue de un solo ambiente o a gran escala (actualizaciones de múltiples ambientes). Usted puede escalar fácilmente la ejecución de los paquetes de pruebas utilizando la infraestructura de auto-escalado de ProcessMaker.
Almacenar las suites de pruebas como código
La intención es almacenar la definición de un conjunto de pruebas como un archivo JSON en un repositorio de código GitHub. El archivo JSON definirá las pruebas a ejecutar con cada prueba que se almacene en el repositorio de código también. Esta utilización de los repositorios de código de git para almacenar los paquetes de pruebas nos permite aprovechar las ramificaciones y otras características de git para controlar y gestionar los paquetes de pruebas. Esto también permite el uso de la ejecución de dichas pruebas, sin el uso de ProcessMaker, localmente para propósitos de desarrollo y depuración.
Entonces, ¿por qué usamos GitHub? Honestamente, porque el wiki de GitHub y el rastreador de problemas nos da la retroalimentación y la documentación detallada que necesitamos. Además, puedes rastrear las revisiones en múltiples versiones. Además, en términos de control de versiones, nos encantan las capacidades de ramificación de Git. A través de las características de ramificación, puedes trabajar en un entorno aislado para cada cambio que necesites hacer en tu código base. Dado que GitHub utiliza un sistema de control de versiones distribuido, cada persona que trabaja en el mismo proyecto puede tener todo su historial guardado en su propio repositorio localizado. Además, si dos colaboradores hacen cambios en el mismo archivo, GitHub combinará inteligentemente las modificaciones. También es bastante fácil volver a una versión específica. En general, permite un ciclo de publicación más rápido y GitHub funciona perfectamente con los entornos de CI/CD.
Conclusión
Cuando se selecciona una herramienta de prueba automatizada, se debe buscar una que sea ágil y que ofrezca soporte para una amplia gama de lenguajes y aplicaciones. Esto permitirá a su equipo contribuir a sus ciclos de pruebas sin necesidad de tener conocimientos técnicos.
