Pruebas de regresión funcional con SOAtest como parte de un proceso de integración continuo

Logre velocidad mientras protege su aplicación contra regresiones

La Integración Continua (“CI”) es una práctica bien entendida y (en este punto) bien adoptada. Es un primer paso necesario para mejorar significativamente la velocidad de entrega de la aplicación.

La Integración Continua permite a los desarrolladores introducir sus cambios en una rama "maestra" del código fuente, con un único desarrollador que puede impulsar muchos cambios a la rama maestra durante un solo día. Para garantizar que la rama principal sea impecable, compilable y de alta calidad, es fundamental realizar pruebas después de cada cambio, ya que sirve como la copia de oro del código fuente de la aplicación.

(Si está interesado en obtener más información sobre la integración continua, le recomiendo el artículo más antiguo pero interesante de Martin Fowler aquí sobre la historia de la integración en el desarrollo de software y los beneficios / mejores prácticas de CI).

Hoy nos centraremos en cómo configurar Parasoft SOAtest para ejecutar pruebas de regresión funcional como parte de un proceso de Integración Continua. En este artículo, describiré los pasos para configurar SOAtest con Jenkins, una popular plataforma de automatización. Usaremos la aplicación Parabank de código abierto y la implementaremos usando Docker para simplificar las cosas.

¿Cómo funcionará esto?

El diagrama a continuación explica lo que configuraremos en este artículo. Es mejor leer de izquierda a derecha.

En resumen, Jenkins comprobará un repositorio de Github que contiene el proyecto SOAtest llamado "Parabank" que contiene pruebas REST. Jenkins también extraerá una imagen de Docker llamada parasoft / parabank de Docker Hub. Esta imagen contiene no solo Parabank, sino también Tomcat y el entorno de ejecución de Java correcto.

Jenkins luego ejecutará una instancia de esta imagen de Parabank (llamada "contenedor"). Luego, Jenkins le dirá a SOAtest que ejecute las pruebas que extrajimos de Github para que podamos validar nuestra instancia de Parabank.

Ahora bien, esto no está en el espíritu de una verdadera integración continua (ya que le estoy dando una aplicación prediseñada), pero quería usar Docker para evitarle la molestia de tener que construir Parabank con Maven y tener que instalar y configurar Tomcat / Java.

A continuación se proporciona un diagrama de CI más realista / del mundo real. El desarrollador comprueba el código fuente en Github. Ahora queremos probar que la aplicación todavía está en buen estado incluso después de los cambios del desarrollador.

El cambio de código fuente en Github desencadena una compilación en Jenkins, y Jenkins inicia una compilación automatizada de Maven (que ejecuta pruebas JUnit). Si todas las pruebas unitarias pasan, la aplicación empaquetada (parabank.war) se implementa en Tomcat. Entonces SOAtest comienza a ejecutar pruebas funcionales de "caja negra".

Solo después de que pasan las pruebas unitarias (durante la compilación de Maven) y las pruebas funcionales de la “caja negra” (durante la ejecución de SOAtest) se consideran buenos los cambios originales del desarrollador.

¡Vayamos a los pasos necesarios para configurar el proceso en el primer diagrama!

Configuración de SOAtest y Jenkins

Requisitos previos:

• Una máquina con Windows 10 capaz de ejecutar Docker (otros sistemas operativos funcionarán, pero algunos de los comandos que proporciono en este artículo pueden tener una sintaxis diferente). Esta máquina debe tener conectividad a Internet.
• Cree un archivo localsettings.properties en algún lugar de su máquina. Copiar el contenido de mi archivo de muestra en ello. Si tiene una licencia de nodo bloqueado, agréguela a la línea 5. Si usa un servidor de licencias, establezca la línea 6 en verdadero y agregue el nombre de host del servidor de licencias en la línea 3. Necesitaremos la ruta a este archivo más adelante.
• Jenkins 1.651 o más reciente instalado en la misma máquina
• SOAtest 9.10 o más reciente instalado y en la RUTA (para que pueda invocar soatestcli desde cualquier directorio) de la misma máquina.
• Docker instalado y en la RUTA de la misma máquina.

Pasos:

1. Inicie sesión en Jenkins en su navegador web (Jenkins generalmente se implementa en una URL como http: // : 8080 / jenkins)
   
2. Comenzaremos instalando algunos complementos de Jenkins. Seleccione "Administrar Jenkins" a la izquierda y luego "Administrar complementos" en el nuevo menú que aparece.
   
   
3. En la pestaña "Disponible", seleccione e instale estos complementos:
   una. "Hallazgos de Parasoft"
   B. "Complemento de Git" (versión 3.30) Seleccione "Instalar sin reiniciar" y luego, en la página de instalación, marque la casilla que dice "Reiniciar Jenkins cuando la instalación esté completa y no se estén ejecutando trabajos"
4. Regrese al paso 1 del formulario del menú principal de Jenkins. A la izquierda, seleccione "Nuevo elemento"
5. Proporcione el nombre "Parabank Deploy and Test" y seleccione el proyecto "Freestyle" y luego OK
6. En el menú de configuración que aparece, desplácese hacia abajo hasta Administración de código fuente y seleccione Git. Agregue esta URL al campo URL del repositorio: https://github.com/sdebrosse/soatest-automation-example.git . Todos los demás campos se pueden dejar con sus valores predeterminados.
7. Desplácese hasta la parte inferior de la página y en Compilar agregue un paso de compilación "Ejecutar comando por lotes de Windows" (si está usando Linux, seleccione "Ejecutar shell" en su lugar):
   
8. Copia el contenido del guión aquí y péguelo en el campo de paso de nueva compilación. Debe cambiar los valores de las dos variables en la parte superior del script para reflejar la ruta a su propio archivo localsettings.properties y dónde desea que se cree un espacio de trabajo temporal (SOAtest creará este espacio de trabajo durante el proceso de prueba). Los comentarios en el guión explican lo que está sucediendo en cada línea:
9. Eso es todo. ¡Ahora estamos listos para ejecutar nuestro trabajo de Jenkins! Asegúrese de cerrar primero todas las instancias abiertas de SOAtest. Luego, seleccione Guardar en la parte inferior del menú de configuración y haga clic en "Construir ahora" a la izquierda:
   
10. Puede hacer clic en el trabajo en ejecución a la izquierda y luego ver la salida de la consola en vivo:
    
    El registro dirá "ÉXITO" al final si todo funcionó correctamente. Esto significa que ha sacado con éxito un proyecto de prueba SOAtest de Github, ha implementado un contenedor Docker con Parabank y ha ejecutado pruebas en esta instancia de Parabank. Al final del proceso, detuvimos automáticamente el contenedor de Parabank y eliminamos nuestro temp_workspace para limpiar nuestro entorno. Pero espere un segundo, es posible que haya notado al mirar los registros que tuvimos algunas fallas en las pruebas ...Sí, algunas de nuestras pruebas contra Parabank fallaron. Si queremos que nuestra compilación de Jenkins falle debido a fallas en la prueba SOAtest, agregamos el indicador -fail cuando invocamos soatestcli. Así: soatestcli.exe -fail -data %TEMP_WORKSPACE_PATH% -resource /Parabank -config “builtin://Demo Configuration” -localsettings %LOCALSETTINGS_PATH%Si abre la prueba en la interfaz de usuario de SOAtest Desktop, descubrirá que esto la falla es principalmente un problema de configuración de datos de prueba/entorno de prueba. Nuestro procesador de préstamos rechazó un préstamo que debería haber aprobado.

¿A dónde vamos desde aquí?

La configuración del entorno de prueba y los datos de prueba son los mayores obstáculos para las pruebas automatizadas confiables. En futuros artículos, exploraré cómo una tecnología llamada virtualización de servicios puede ayudar a garantizar que siempre tengamos la configuración de entorno exacta que necesitamos para ejecutar nuestras pruebas de manera confiable en cualquier momento; esto nos llevará de la Integración continua al mundo de la Continua. Pruebas.

Por Spencer Debrosse