Los pasos a seguir son simples:
1. Construir un servicio y exponerlo en OSB.
2. Crear un proyecto de SOAP UI para probar el servicio.
3. Hacer uso de Maven para probar y desplegar el proyecto.
Imaginemos el siguiente escenario: tenemos un servicio en un entorno de desarrollo (desplegado) y lo queremos promover a un ambiente de pruebas. Previo a realizar esto, debemos asegurarnos que nuestro servicio funciona de manera adecuada y que hace lo que debe hacer.
Para ese propósito ocupamos SOAP UI, generamos algunos casos de prueba y los colocamos en una Test Suite y probamos. Una vez que aseguramos que todos los casos de prueba se ejecutan correctamente, podemos pasar a la automatización de esas pruebas.
En mi caso, creé un servicio simple que devuelve un saludo (cómo crear el servicio, esquemas, pipeline, etc., no es el objetivo de esta entrada pero pueden crear uno muy simple). Posteriormente, creé el proyecto en SOAP UI, una Test Suite (llamada Pruebas) y un Test Case (saludar TestCase). Agregué un par de pasos de ejecución para las pruebas y algunos assertions para cada paso. Ejecuté el test case y estos fueron mis resultados:
Al ejecutar cada uno de los pasos, mis resultados fueron los siguientes:
Como vemos, el servicio cumple con los casos de prueba diseñados. Esto podría significar que está listo para ser promovido a un ambiente de pruebas. Para asegurarnos que el código que estamos desplegando esté bien probado antes de ser promovido, y que esto se haga de forma automática, podemos hacer uso de un plugin de Maven. Esto es tan simple como agregar lo siguiente al POM del proyecto:
<pluginRepositories>
<pluginRepository>
<id>smartbear-sweden-plugin-repository</id>
<url>http://www.soapui.org/repository/maven2/</url>
</pluginRepository>
</pluginRepositories>
<build>
<plugins>
<plugin>
<groupId>com.smartbear.soapui</groupId>
<artifactId>soapui-maven-plugin</artifactId>
<version>4.6.1</version>
<executions>
<execution>
<id>QClearanceTest</id>
<goals>
<goal>test</goal>
</goals>
<phase>test</phase>
</execution>
</executions>
<configuration>
<projectFile>${basedir}/Test/test-soapui-project.xml</projectFile>
<testSuite>Pruebas</testSuite>
<testCase>saludar TestCase</testCase>
<endpoint>http://localhost:7001/v1/SOAPUI/TestSuite.svc</endpoint>
<outputFolder>${basedir}/Reporte</outputFolder>
<junitReport>true</junitReport>
<printReport>true</printReport>
<settingsFile>${basedir}/Test/soapui-settings.xml</settingsFile>
</configuration>
</plugin>
</plugins>
</build>
Lo que marco en naranja, es básicamente lo que tendría que cambiar de acuerdo a cómo hayan hecho la implementación del servicio. En mi caso:
- El endpoint de mi servicio está en localhost, por el puerto 7001
- La Test Suite de SOAP UI, la llamé Pruebas
- El Test Case de SOAP UI, lo llamé saludar TestCase
- En caso de haber un error en las pruebas, quiero que se genere un reporte debajo de la carpeta ${basedir}/Reporte (donde tengo mi proyecto de OSB, debajo de una carpeta llamada Reporte).
- Tanto el proyecto de SOAP UI, como el archivo de instalación del producto, los puse debajo de la carpeta Test.
Así quedó la estructura de mi proyecto de OSB:
- Reporte, es la carpeta donde el plugin va a almacenar el reporte de ejecución de las pruebas
- Test, es la carpeta donde coloqué el XML del proyecto de SOAP UI (test-soapui-project.xml) y el XML de la instalación del producto (soapui-settings.xml)
Hay algunas consideraciones respecto al proyecto de SOAP UI para que pueda funcionar bien el plugin:
- SOAP UI por default coloca "\r" al finalizar una línea en los payloads de prueba. Esto se ve en el XML del proyecto de SOAP UI. Simplemente hay que eliminar las "\r".
- SOAP UI por default coloca "No Authorization" cuando no tenemos algún tipo de autorización. Esto se valida en un enumeration de un esquema, y "No Authorization" no es parte de ese enumeration. Así es que hay que eliminarlo (o comentarlo en el código).
Entonces, el proyecto de SOAP UI que adjuntamos a nuestro proyecto de OSB, se debe corregir de la siguiente forma (izquierda: incorrecto, derecha: correcto):
Una vez corregido el proyecto de SOAP UI, lo podemos probar localmente ejecutando mvn test:
Lo más importante de haber logrado automatizar las pruebas, es que esto se incluya antes del despliegue. Para esto, debemos haber poblado nuestro repositorio local con los artefactos de Oracle, para así poder ejecutar: mvn pre-integration-test. La documentación de cómo hacer esto, la pueden encontrar aquí:
Lo anterior, realizará las pruebas previo al despliegue del servicio (en el ambiente indicado). Entonces, al ejecutar mvn pre-integration-test, tendremos lo siguiente (además del servicio probado y desplegado en el ambiente destino):
Podría concluir que el uso del plugin de SOAP UI es muy útil para validar que nuestros servicios se comporten de la manera en que se espera, previo al despliegue a un ambiente de calidad o productivo. En conjunto con los artefactos de Oracle, esto puede ser un buen inicio para automatizar las pruebas y despliegues, generando así los primeros pasos de un entorno de CI/CD.
Además nos obligamos a diseñar y ejecutar casos de prueba. Es muy importante entender que los defectos deben ser encontrados y corregidos (en su mayoría) por el desarrollador, no por el equipo encargado de realizar QA. Si diseñamos y ejecutamos esas pruebas previo al despliegue, minimizamos la cantidad de defectos que pudieran ser encontrados después. Entre más robusto sea el diseño de esos casos de prueba, entregaremos un producto de mejor calidad y con menor número de defectos. Hagamos ésta una práctica del equipo de desarrollo.
No hay comentarios.:
Publicar un comentario