Las pruebas de integración siguen siendo una parte importante del ciclo de producción de CI / CD, incluido el desarrollo de aplicaciones en contenedores. Las pruebas de integración, por regla general, no son muy largas, pero requieren cargas de trabajo muy intensivas en recursos. Veamos cómo puede combinar tecnologías y herramientas de pruebas de integración con herramientas de orquestación de contenedores (en particular, con
Red Hat OpenShift ) para acelerar las pruebas, aumentar su dinamismo y usar los recursos de manera más eficiente.
Creemos pruebas BDD de integración (
desarrollo basado en el comportamiento ) usando
Cucumber ,
Protractor y
Selenium y ejecútelas en la plataforma OpenShift usando Zalenium.
Prueba de BDD
Al desarrollar pruebas de integración, BDD permite a los analistas de negocios (BA) crear definiciones de pruebas de integración, no solo programadores. Gracias a BDD, el proceso de desarrollo se puede organizar de modo que los requisitos funcionales y las definiciones de las pruebas de integración se preparen al mismo tiempo y al mismo tiempo que sean creados por analistas comerciales.
Esto es mucho mejor que los enfoques tradicionales, cuando primero determina la funcionalidad comercial de la aplicación, y luego el departamento de control de calidad (QA) crea pruebas de integración, como se muestra en el siguiente diagrama:
Y así es como se ve cuando se usa BDD:
Además, en este nuevo esquema, cada iteración generalmente toma menos tiempo.
Los analistas de negocios pueden crear definiciones para las pruebas de integración porque BDD describe estas pruebas en un lenguaje
Gherkin simple y comprensible cuyas palabras clave principales son Given, When y Then Cada declaración en el idioma de Gherkin debe comenzar con una de estas palabras.
Por ejemplo:Dado que el usuario navegó a la página de inicio de sesión (siempre que el usuario haya accedido a la página de inicio de sesión)
Cuando el usuario ingresa nombre de usuario y contraseña
Cuando el nombre de usuario y la contraseña son correctos
Luego, el sistema los registra (entonces el sistema le permite iniciar sesión)Un tiempo de ejecución popular que puede interpretar las pruebas de pepinillo es el
pepino . Para usar Cucumber, un desarrollador debe implementar ciertas funciones para poder ejecutar cualquier directiva Gherkin. Pepino tiene enlaces a muchos lenguajes de programación. Se recomienda (pero no es obligatorio) que las pruebas se escriban en el mismo idioma que la aplicación que se está probando.
Pila de tecnología de prueba
Echemos
un vistazo al procedimiento de prueba utilizando la aplicación web
TodoMVC como
ejemplo en la
implementación de AngularJS . AngularJS es un marco popular para crear aplicaciones de una sola página (SPA).
Como AngularJS es JavaScript, usaremos
Cumcumber.js , enlace de Pepino a JavaScript.
Para emular el trabajo del usuario en un navegador, utilizaremos
Selenium . Selenium es un proceso que puede iniciar un navegador y reproducir acciones de los usuarios en los comandos recibidos a través de la API.
Finalmente, usaremos
Protractor para tener en cuenta los matices de emular aplicaciones SPA escritas en AngularJS. El transportador se encargará de la expectativa de que las vistas dentro de la página se carguen correctamente.
Entonces, nuestra pila de pruebas es la siguiente:
El proceso presentado en este diagrama se describe a continuación:
- Cuando se ejecuta la prueba de Cucumber, Cucumber lee la definición de prueba del archivo Gherkin.
- Luego comienza a llamar al código de implementación del código de prueba.
- El código de implementación del script de prueba utiliza Protractor para realizar acciones en una página web
- Cuando esto sucede, Protractor se conecta al servidor de Protractor y emite comandos a Selenium a través de la API.
- Selenium ejecuta estos comandos en una instancia del navegador.
- El navegador, si es necesario, se conecta a los servidores web. En nuestro ejemplo, se utiliza la aplicación SPA, por lo tanto, dicha conexión no se produce, ya que la aplicación ya se ha cargado al cargar desde el servidor de la primera página.
Implementar tal pila en una infraestructura no en contenedores no es fácil. Y no solo por la gran cantidad de procesos y marcos utilizados, sino también porque iniciar un navegador en un servidor sin monitor siempre ha sido difícil. Afortunadamente, en un mundo en contenedores, todo esto puede ser automatizado.
Granja de pruebas de integración
Las aplicaciones web empresariales deben probarse para varias combinaciones del sistema operativo cliente y el navegador. Por lo general, esto se limita a un cierto conjunto básico de opciones que refleja la situación en las máquinas de los usuarios finales de la aplicación. Pero incluso en este caso, el número de configuraciones de prueba para cada aplicación rara vez cae por debajo de media docena.
Si implementa constantemente una pila para cada configuración de prueba y ejecuta las pruebas correspondientes en ella, entonces esto es demasiado costoso en términos de tiempo y recursos.
Idealmente, me gustaría ejecutar pruebas en paralelo.
Selenium-Grid puede ayudarnos con esto: una solución que incluye el agente de solicitudes Selenium Hub y uno o más nodos en los que se ejecutan estas solicitudes.
Cada nodo Selenium que generalmente se ejecuta en un servidor separado se puede configurar para una combinación específica de SO cliente y navegador (en Selenium, estas y otras características del nodo se denominan capacidades). Al mismo tiempo, Selenium Hub es lo suficientemente inteligente como para enviar solicitudes que requieren ciertas propiedades de Selenium a los nodos que tienen estas propiedades.
Los clústeres de Selenium-Grid son bastante difíciles de instalar y administrar, y tanto que incluso las compañías que ofrecen servicios relacionados han aparecido en el mercado. En particular, SauceLabs y BrowserStack se encuentran entre los principales jugadores.
Pruebas de integración basadas en contenedores.
Muy a menudo, me gustaría poder crear un clúster de cuadrícula de selenio que proporcione las propiedades de selenio necesarias para nuestras pruebas y ejecutar las pruebas con un alto grado de paralelización. Luego, después de completar las pruebas, me gustaría poder destruir completamente este clúster. En otras palabras, aprender a trabajar de la misma manera que los proveedores de granjas de pruebas de integración trabajan ellos mismos.
Esta área de tecnología aún se encuentra en una etapa temprana de formación, sin embargo, un prometedor proyecto de código abierto,
Zalenium , ofrece algo de lo que necesitamos.
Zalenium utiliza un Hub modificado que puede crear nodos bajo demanda y destruirlos cuando ya no se necesitan. Actualmente, Zalenium solo es compatible con los navegadores Chrome y Firefox en la plataforma Linux. Pero con la llegada de los nodos de Windows para Kubernetes, puede aparecer la compatibilidad con Explorer y Edge en Windows.
Si pones todo junto, entonces la pila tecnológica es la siguiente:
Cada óvalo en el diagrama es una vaina separada en Kubernetes. Las cápsulas del jugador de prueba y los emuladores son efímeras y se destruyen al final de la prueba.
Realizar pruebas de integración dentro de la canalización de CI / CD
Creemos una tubería simple en Jenkins para mostrar cómo integrar este tipo de pruebas de integración en el resto del proceso de administración de versiones. Se ve así:
Su canalización puede variar, pero aún tiene la oportunidad de reutilizar la fase de prueba de integración sin una refactorización de código significativa.
Como la mayoría de los hogares son efímeros, una de las tareas de la tubería es recopilar los resultados de las pruebas. En Jenkins, esto se puede hacer usando el archivo y publicar primitivas HTML.
Y este es un ejemplo de un informe sobre los resultados de las pruebas (tenga en cuenta que las pruebas se ejecutaron en dos navegadores):
Conclusión
Por lo tanto, a pesar de la complejidad de organizar una infraestructura de prueba de integración de extremo a extremo, el enfoque de "infraestructura como código" simplifica el proceso. La realización de pruebas de integración en varias combinaciones de SO y navegadores requiere mucho tiempo y recursos, pero las herramientas de orquestación de contenedores y las cargas de trabajo efímeras ayudan a hacer frente a este problema.
Incluso en ausencia de herramientas maduras para organizar pruebas de integración orientadas a contenedores, las pruebas de integración basadas en plataformas de contenedores ya pueden llevarse a cabo hoy y aprovechar el enfoque de contenedor.
Si está desarrollando aplicaciones en contenedores, intente utilizar este enfoque dentro de la canalización de CI / CD y vea si ayuda a simplificar las pruebas de integración.
El código de muestra de este artículo se puede encontrar en el sitio web de GitHub en redhat-cop / container-pipelinesh.