Ejecutando test de SoapUI Open Source en JUnit en un proyecto Maven

En este tutorial vamos a ver cómo podemos ejecutar los tests de SoapUI desde nuestros @Test de JUnit en un proyecto Maven.

0. Indice de contenidos

• 1. Introducción
• 2. Entorno
• 3. Preparando el proyecto de SoapUI
  • 3.1. El test
  • 3.2. El servidor
  • 3.3. Preparando el test de SoapUI
  • 3.4. Las «Custom Properties»
• 4. Creando el proyecto de Maven
  • 4.1. Incluyendo soapui.jar
  • 4.2. El resto de dependencias
• 5. Creando los @Tests de JUnit
  • 5.1. Ejecución de todos los test del fichero.
  • 5.2. Ejecución de TestCase específicos de SoapUI.
• 6. Ficheros extra de salida
• 7. Conclusiones

1. Introducción

El desarrollo de aplicaciones actualmente pasa por exponer o consumir ciertos servicios: bien por arquitecturas orientadas a servicios (SOA), por la publicación de servicios REST para comunicarse con el mundo exterior, o bien por el boom de los microservicios, que dividen los grandes monolitos en pequeñas microaplicaciones que se comunican a través de servicios empleando unos u otros protocolos.

Esto nos lleva inevitablemente, dentro de un desarrollo responsable en el que existe el testing, a tener que probar estos servicios a través de test de integración. Estos test los podemos programar con Java, o para algunos casos, podemos usar herramientas especializadas como SoapUI.

En este tutorial vamos a cubrir el espacio que hay entre nuestros test unitarios como desarrolladores realizados en JUnit o equivalentes, y los test realizados con la herramienta SoapUI: automatizaremos el lanzamiento y recogida de resultados de los test de SoapUI desde nuestro código Java. De este modo podremos incluir los test de SoapUI dentro del entorno de integración continua, como un test (de integración) más.

¿Y por qué queremos hacerlo? Pues ya deberías saber a estas alturas que una de las máximas de los test: sirven para que los desarrolladores podamos regular nuestro nivel de stress :). Cuanto más y mejores son los test, menos stress tendremos.

2. Entorno

Cualquier sistema que pueda ejecutar un proyecto maven y SoapUI nos vale:

• Hardware: Acer Aspire One 753 (2 Ghz Intel Celeron, 4GB DDR2)
• Sistema Operativo:Ubuntu 16.04
• Soap UI Open Source versión 5.2.1
• Eclipse Mars
• Java 1.7, Maven 3

El código de este tutorial puede ser descargado en: https://github.com/4lberto/soapUiJunit

3. Preparando el proyecto de SoapUI

No voy a hablar aquí de SoapUI en detalle porque ya tenemos tutoriales para eso, como por ejemplo: https://www.adictosaltrabajo.com/tutoriales/introduccion-soap-ui/, pero sí que vamos a ver lo mínimo para afrontar este tutorial.

Básicamente, SoapUI es una herramienta gráfica preparada para desarrollar test contra servicios de diferente naturaleza, especialmente SOAP y REST.

Se define un «proyecto» que en su interior contiene una «suite de test». En cada suite de test se incluyen casos de prueba o «test cases», dentro de cada uno están los «test steps», que realizan una operación y que contienen unos asserts de validación. Si todos los «test steps» de un «test case» están en verde (pasan los asserts), el test case estará verde. No es muy complicado.

3.1. El test

Para este tutorial he hecho un test muy sencillo. Consiste en:

1. Hacer una llamada REST con el verbo GET a http://localhost:3000/rest/NOMBRE
2. Comprobar que en la respuesta del servidor se devuelve «NOMBRE»

Con esto tendremos suficiente para probar con JUnit que:

• El test se lanza desde JUnit y devuelve un valor de «success»
• El valor que se devuelve es el que se ha enviado

3.2. El servidor

Como se trata de tener un servicio REST de ejemplo para el tutorial, simplemente he creado con Express en NodeJS un servidor con una ruta como la siguiente:

var express = require('express');
var router = express.Router();

router.get('/:name', function(req, res, next) {
  var persona={persona:req.params.name};
  res.send(persona);
});

module.exports = router;

Así que para una URL: http://localhost:3000/rest/NOMBRE, devuelve un JSON como el siguiente:

{"persona":"NOMBRE"}

Tú seguro que tienes algún otro servicio que probar que te es mucho más interesante. Cámbialo por el tuyo y te será de utilidad :).

3.3. Preparando el test de SoapUI

Vamos a utilizar la versión Open Source de SoapUI, que nos da menos facilidades que la versión de pago, y que seguramente será la que estás usando si la empleas circunstancialmente. Además, lo que veamos aquí también sirve para la profesional.

Se siguen estos pasos:

1. Menú File > New REST Project
2. Incluimos la URL de nuestro servidor, que es http://localhost:3000

   

3. Abrimos el «resource viewer» que está en la rama debajo de la URL del servidor. Este recurso apuntará a un recuros REST del servidor

   

4. Introducimos en el campo «Resource Path» el valor /rest/${#TestCase#name} que hace referencia al recurso «rest» y al valor «name» que daremos posteriormente en las propiedades del «TestCase», que es el nombre que le hemos dado al Test Case. Debería quedar algo así:

   

   .

5. Haciendo click secundario sobre el proyecto, en el menú indicaremos «New Test Suite».
6. Haciendo click secundario sobre el Test Suite, en el menú indicaremos «New Test Case».
7. Expandiendo el árbol, llegaremos hasta «Test Step». Haciendo click secundario > Add Step > REST Reques y seleccionaremos el primer método para la request, que incluye la llamada al recurso:

   

8. Finalmente seleccionaremos «Test Case» y abajo de la pantalla a la izquierda seleccionaremos la pestaña «Custom Properties». Pulsaremos sobre el icono verde «+» y añadiremos una propiedad con los valores «name» y «luis» por ejemplo.

   

Nos queda el paso de validación con los asserts antes de ejecutar el caso. Si no, no devolverá nada (ni verde ni rojo). Es muy fácil:

1. Hacemos doble click sobre el nombre del paso del test que hemos creado dentro de «Test Steps». Aparecerá una ventana.
2. En la ventana, abajo a la izquierda, aparece «Assertions (0)». Haz click para que se expanda un rectángulo con los asserts. De momento está vacío.
3. Pulsa sobre la cruz verde para añadir uno nuevo. En la venta elige «Property Content» a la izquierda y a la derecha «Contains». Pulsa abajo sobre el botón «Add». Y dentro indica que tiene que contener el valor de la custom property, que es ${#TestCase#name}:
   

   

Ahora, si tenemos el servidor levantado, podremos ir al Test Case, hacer doble click y ejecutar el caso. Yo he conseguido que funcione, así que tengo un verde y si voy a la respuesta en JSON veo que devuelve «luis». Cuando usemos JUnit cambiaremos ese «luis» por otra cosa.

3.4. Las «Custom Properties»

Si has prestado atención, antes he indicado que en el Test Case se debe indicar una «Custom Propertie», que era «name» y le hemos dado un valor de «luis».

Esta property será la que personalicemos cuando lancemos el caso desde JUnit, puesto que admite por parámetro un mapa de propiedades. Simplemente indicaremos que hay una propiedad «name» con el valor que indiquemos en el test, sobreescribiendo a «luis».

Como en SoapUI indicamos tanto para el parámetro como para el assert del paso del test, que lea ${#TestCase#name}, no habrá que editar el SoapUI para cada caso… Por cierto, ${#TestCase#name}, es la notación de scripts de Soap para acceder a una variable declarada.

4. Creando el proyecto de Maven

Ya tenemos el proyecto SoapUI creado, ahora lo vamos a ejecutar con JUnit en un proyecto Maven. Si no usásemos Maven, sino un proyecto de Eclipse normal y corriente, las cosas serían más fáciles… pero no vamos a renunciar a la gestión de dependencias y del ciclo de vida que nos da Maven sólo porque sea más complicado 🙂

¡Importante! El proyecto de SoapUI que acabamos de crear, lo dejaremos en el directorio src/test/resources del proyecto Maven que estamos creando.

4.1. Incluyendo soapui.jar

Si seguimos las instrucciones oficiales de SoapUI para poder utilizarlo, se trata de ir al directorio «bin» de la instalación de SoapUI y tomar el fichero «soapui-5.2.1.jar» para incluirlo en nuestro proyecto.

Como decía, hacer esto en Eclipse es más sencillo a golpe de Clicks, pero par amaven hay que montar un repositorio. Lo ideal es tener un repositorio como Nexus en el que subir los artefactos y usarlo, pero voy a usar una técnica un poco más «chapuzas» ya que estamos haciendo una prueba «piloto» y cómo no, en sincero homenaje a Ángel de Andrés.

Se trata de copiar el fichero soapui-5.2.1.jar en «src/test/resources» como recurso simple para los test.

Seguidamente se va al pom.xml y se declara un repositorio con la siguiente sintaxis:

<repositories>
...
    <repository>
        <id>my-local-repo</id>
        <url>${project.basedir}/src/test/resources/</url>
    </repository>
...
</repositories>

con esto indicamos que hay un repositorio de archivos en esa dirección. Y luego usamos el artefacto:

<dependency>
    <groupId>com.smartbear.soapui</groupId>
    <artifactId>soapui</artifactId>
    <version>5.2.1</version>
</dependency>

¡Ojo! ¡No uses esto en producción ni para nada que requiera un mínimo de seriedad

4.2. El resto de dependencias

Aquí está la mayor dificultad de este tutorial. La librería de SoapUI tiene bastante dependencias que hay que resolver. Según su documentación oficial, se debe incluir el directorio «lib» de la instalación de SoapUI en el proyecto, que son decenas de archivos .jar… E incluirlos en Eclipse es fácil, pero en Maven hay que ir uno por uno.

En un primer intento traté de localizar los artefactos en maven central, pero es una tarea demasiado complicada.

Al final decidí ir al repositorio de GitHub de la versión Open Source y «robarles» las dependencias de su pom.xml.

Dentro de toda la estructura de SoapUI Open Source, se puede ver que hay 4 proyectos hijos de maven, y dentro de uno de ellos, «soapui», están las dependencias que necesitamos. Concretamente en https://github.com/SmartBear/soapui/blob/next/soapui/pom.xml. Bueno, en realidad hay más… he intentado limpiar algunas en mi versión de GitHub que puedes consultar aquí:https://github.com/4lberto/soapUiJunit

Si todo está bien, al menos en mi repositorio de GitHub a la hora de hacer este tutorial, debería estar todo lo necesario para poder trabajar con la versión 5.2.1

5. Creando los @Tests de JUnit

Y ahora llegamos a la parte buena… la de los test de JUnit donde vamos a utilizar las librerías que hemos incluido antes para ejecutar el test…

Hay dos métodos para ejecutar nuestro test:

• Ejecución de todos los test del fichero de SoapUI que estemos manejando.
• Ejecutar solamente un test case particular.

Vamos a ver las diferencias de código entre uno y otro.

Por cierto, el fichero que hemos creado anteriormente con los test, estará en: «src/test/resources/REST-Project-1-soapui-project.xml»

5.1. Ejecución de todos los test del fichero.

Tienen la parte negativa de que no permite hacer asserts sobre el resultado, ya que este es global, por lo que el control es mejor. Quizá si preparamos los tests en SoapUI de forma adecuada nos pueda servir.

private static final String TEST_FILE = "src/test/resources/REST-Project-1-soapui-project.xml";

@Test
	public void shouldExecuteAllTestCases() throws Exception{
			SoapUITestCaseRunner soapUITestCaseRunner = new SoapUITestCaseRunner();
		    soapUITestCaseRunner.setProjectFile(TEST_FILE);
		    soapUITestCaseRunner.run();
		    //No asserts in this mode
	}

Como puedes ver no hay asserts en esta parte. Podrías tomar el resultado del método «run()» que es un boolean para hacer una comprobación y que saliese el semáforo verde en JUnit…

¡Ah! Este es el modo que se usa cuando se emplea como plugin de maven para ejecutar los test de un fichero cuando se ejecuta como tarea.

5.2. Ejecución de TestCase específicos de SoapUI.

Pero también podemos ejecutar los casos de test específicos que contenga el proyecto de SoapUI, y lo que es mejor, nos permite, entre otras cosas:

• 1. Personalizar los parámetros de entrada.
• 2. Recoger el resultado del test y poder incluirlo en un assert.

Aquí tenemos un ejemplo de @Test de JUnit que ejecuta un testCase llamado «TestCase» dentro de «TestSuite» 10 veces con diferente parámetro:

private static final String TEST_FILE = "src/test/resources/REST-Project-1-soapui-project.xml";

@Test
	public void shouldExecuteSpecificTestCase() throws XmlException, IOException, SoapUIException {
		// given
		WsdlProject project = new WsdlProject(TEST_FILE);
		TestSuite testSuite = project.getTestSuiteByName("TestSuite");
		TestCase testCase = testSuite.getTestCaseByName("TestCase");

		for (int i = 0; i < 10; i++) {

			PropertiesMap propertiesMap = new PropertiesMap();
			//Sets parameter defined in Soap UI teste case
			testCase.setPropertyValue("name", "aName_" + i);

			TestRunner runner = testCase.run(propertiesMap, false);
			assertEquals(Status.FINISHED, runner.getStatus());
		}
	}

Por cada uno de ellos se hace una comprobación del estado para asegurarnos de que cada test ha acabado correctamente. Ten en cuenta que esto está condicionado por los asserts que se hayan puesto en el test de SoapUI…

En los JavaDoc de la API de SoapUI Open Source (https://www.soapui.org/soapui-projects/soapui-projects.html) podemos encontrar más métodos del TestRunner que nos devuelven más información sobre cómo ha ido el test:

Una cosa tremendamente interesante es la posibilidad de establecer aquí las propiedades a nivel de Test Case. Si recuerdas, al hacer el test en SoapUI hemos indicado que en el Test Case haya una propiedad llamada «name» y que tenía un valor llamado «luis». Ahí, te dije que se podría incluir un mapa para alterar ese parámetro en cada llamada. Pues ahí lo tienes:

PropertiesMap propertiesMap = new PropertiesMap();

testCase.setPropertyValue("name", "aName_" + i);

TestRunner runner = testCase.run(propertiesMap, false);

Entonces en cada iteración del bucle, se mandará «aName_1», «aName_2″… Esta es la traza del servidor por si no te lo crees :).

Y como se cumplen los asserts de SoapUI y por tanto el estado de los test es Finished, todo aparece en verde 🙂

6. Ficheros extra de salida

Cuando ejecutes los test, verás que en el directorio raíz del entorno de ejecución (en este caso la base desde la que salen «src»), aparecerán unos ficheros de log con trazas sobre las operaciones de test que se han hecho con SoapUI. Por enumerarlos:

• global-groovy.log: la salida de los scripts de setup y tear-down que se han escrito en SoapUI utilizando Groovy. En este ejemplo dejado una simple traza con log.info.
• soapui-errors.log: trazas de error de SoapUI por no encontrar clases por ejemplo.
• soapui.log: el log de SoapUI al ejecutarse.

Simplemente ten en cuenta estos ficheros si las cosas no van bien… ¡te servirán de gran ayuda para rastrear los problemas!.

7. Conclusiones

En este tutorial hemos visto cómo podemos automatizar utilizando JUnit el lanzamiento de test de SoapUI Open Source, y así poder incluirlo en nuestra «red de seguridad» de desarrollo ágil, es decir, en nuestro sistema de integración continua.

Aunque existen otras alternativas, como por ejemplo utilizar un plugin de Maven o adquirir la versión Profesional del producto (de pago) o emplear el lanzamiento desde la línea de comandos, utilizar JUnit puede facilitar la realización de comprobaciones de grano fino y más controlables, incluso parametrizando las entradas para test de stress o comprobar un gran número de parámetros.

Espero que te sirva de ayuda para dormir un poco más tranquilo, estando seguro de que el código de tus servicios REST o SOAP está más que probado 🙂