El objetivo que persigue la serie de artículos que comienza hoy es conocer los beneficios que aporta la herramienta de testing SoapUI. La estrategia que se seguirá en ellos es realizar la instalación, mostrar algunas funcionalidades importantes y mostrar ejemplos donde aplicar pruebas unitarias manuales y/o automatizadas.
En este primer artículo nos centraremos en la funcionalidad de realizar pruebas unitarias de servicios web REST API disponibles en la herramienta.
1. Instalación y Requisitos del Sistema
Como requisito previo , para poder ejecutar soapUI, debes tener ejecutándose en tu sistema operativo Java Development Kit (JDK) v1.6 o superior. Como soapUI está implementado en Java, necesita de este software adicional. Si no dispone de él, puede descargarlo desde su página oficial:
https://www.oracle.com/java/technologies/downloads/
Podemos descargar la versión open source desde su página oficial:
https://www.soapui.org/downloads/soapui/
La instalación es sencilla, únicamente debemos seguir los pasos que nos proporciona el instalador. Al finalizar dicha instalación, obtendremos un icono para abrir SoapUI en el escritorio:
2. Servicio REST API a consultar:
En primer lugar, para poder realizar nuestras pruebas, necesitaremos un dominio web que ofrezca acceso gratuito a la información de un sistema de base de datos a través de peticiones a métodos genéricos HTTP = Get/Post/Put/Delete.
Para este artículo, haremos uso de algunos de los datos de usuarios disponibles y sus métodos asociados, que provee para pruebas la web: https://dummyjson.com
La información disponible en una REST API se diseña en torno a recursos, que son cualquier tipo de dato al que se puede acceder. Un recurso tiene un identificador, que es una URI (identificador uniforme de recursos) que lo identifica de forma única.
3. Creación del Proyecto
Crearemos un nuevo proyecto REST API:
En el nuevo cuadro emergente, insertaremos un ejemplo de petición GET al recurso “user”:
Tras pulsar en el boton “OK”, en la sección Navegación, se nos generará el nuevo proyecto con varios atributos que describiremos desde la imagen a continuación:
4. Introducción a la Interfaz
Hagamos una pausa un momento para observar varias secciones importantes de la interfaz que la herramienta pone a nuestra disposición:
- La sección “Navegación” donde visualizar tanto los recursos y métodos del proyecto como las posibles suites de pruebas y casos de prueba que puedan generarse.
- La sección “Peticiones” donde para cada una de las llamadas podemos definir los diferentes elementos que lo componen y los posibles parámetros necesarios que insertar.
- La sección “Respuesta” donde podemos visualizar las respuestas recibidas en el formato preferido (Json, Xml, Html o Raw).
5. Lanzamiento de Petición y verificación de respuesta
Para lanzar cualquier petición insertada, tendremos que pulsar sobre el botón "Play" indicado con un icono verde:
Como respuesta de esta petición, visualizaremos el formato ofrecido por el servicio web dentro de la sección "Respuesta"de la parte derecha:
Recomendamos tener seleccionada la pestaña “Representation” o “Header” en la parte inferior de esta sección para verificar más rápidamente los atributos de estas respuestas.
6. Crear nuevos recursos secundarios
Como hemos indicado anteriormente, la información disponible en una REST API se diseña en torno a recursos, pero estos recursos pueden estar generados habitualmente de forma jerárquica.
Vamos a crear las siguientes peticiones a los métodos HTTP y así observaremos cómo generar nuevos recursos jerarquizados y que se encuentren bajo el creado previamente “user”.
6.1. Petición GET Search User
Para esta nueva petición, tendremos que posicionarnos en el recurso “user” y pulsar en el botón secundario del ratón para seleccionar la opción “New Child Resource”:
En la nueva ventana emergente, insertaremos el nuevo recurso “search” haciendo uso de su ubicación a partir del anterior recurso "user" ya creado.
Como también hemos insertado los parámetros por lo que realizar la búsqueda, por defecto ya se han generado estos parámetros en esta petición GET.
NOTA IMPORTANTE = Dentro del atributo “Level” de los parámetros tendremos el nivel de ámbito de uso de este atributo:
- RESOURCE (Recurso) = Este nivel es utilizado para que el atributo sea compartido por todos los métodos bajo el mismo recurso.
- METHOD ( Método) = Este nivel es utilizado para que de forma única este atributo sea aplicable al método en el que se generó. ( Recomendado en nuestro caso)
Veamos ahora la respuesta del lanzamiento de la petición:
6.2. Petición POST Add User
Para esta petición, de forma similar , tendremos que posicionarnos de nuevo en el recurso “user” y pulsar en el botón secundario del ratón para seleccionar la opción “New Child Resource”.
En la nueva ventana emergente, insertaremos la ubicación del recurso "add", pero sólo desde el anterior recurso "user" ya creado.
Se generará por defecto una petición GET, pero basta con realizar el cambio de método a POST e insertar como cuerpo del mensaje la información del nuevo usuario a generar dentro de la sección "Peticiones":
{
"firstName": "Scott",
"lastName": "Davis",
"maidenName": "Martin",
"age": 31,
"gender": "male",
"email": "davisMS@umich.edu",
"phone": "+48 143 590 6847",
"username": "davisMS",
"password": "5t6q4KC7O",
"birthDate": "1982-12-18",
"image": "https://robohash.org/perferendisideveniet.png",
"bloodGroup": "O−",
"height": 170,
"weight": 107.2,
"eyeColor": "Blue",
"hair": {
"color": "Blond",
"type": "Wavy"
},
"domain": "ow.ly",
"ip": "97.11.116.84",
"address": {
"address": "81 Seaton Place Northwest",
"city": "Washington",
"coordinates": {
"lat": 38.9149499,
"lng": -77.01170259999999
},
"postalCode": "20001",
"state": "DC"
},
"macAddress": "42:87:72:A1:4D:9A",
"university": "Poznan School of Banking",
"bank": {
"cardExpire": "02/24",
"cardNumber": "6331108070510590026",
"cardType": "switch",
"currency": "Zloty",
"iban": "MT70 MKRC 8244 59Z4 9UG1 1HY7 TKM6 1YX"
},
"company": {
"address": {
"address": "816 West 19th Avenue",
"city": "Anchorage",
"coordinates": {
"lat": 61.203221,
"lng": -149.898655
},
"postalCode": "99503",
"state": "AK"
},
"department": "Support",
"name": "Balistreri-Kshlerin",
"title": "Quality Engineer"
},
"ein": "51-7727524",
"ssn": "534-76-0952",
"userAgent": "Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.66 Safari/535.11"
}
Veamos ahora la respuesta del lanzamiento de la petición:
6.3. Petición GET Info 100 User
Para esta petición, de forma similar a las anteriores, podremos generar el siguiente recurso:
que nos generará de forma automática esta petición GET:
Veamos ahora la respuesta del lanzamiento de la petición:
7. Crear nuevas peticiones a métodos HTTP sobre un mismo recurso
Además de lo anterior, necesitaremos generar peticiones a métodos HTTP que se encuentren bajo un mismo recurso.
Vamos a crear las siguientes peticiones bajo el recurso previamente generado “users/100”.
7.1. Petición PUT 100 User
Método para actualizar la información sobre el usuario 100. Para ello, tendremos que posicionarnos en el recurso “100” y pulsar en el botón secundario del ratón para elegir la opción “New Method”:
Dentro del nuevo cuadro emergente, insertaremos la definición de la petición:
e insertamos como cuerpo del mensaje la información a actualizar del usuario 100:
{
"age": 41,
"hair":{
"color": "Grey",
"type": "Straight"
}
}
Veamos la respuesta del lanzamiento de la petición:
7.2. Petición DELETE 100 User
Método para borrar la información sobre el usuario 100. Para ello, tendremos que posicionarnos de forma similar en el recurso “100” y pulsar en el botón secundario del ratón para elegir la opción “New Method”.
También de forma similar, dentro del nuevo cuadro emergente, insertaremos la definición de la petición:
Veamos la respuesta del lanzamiento de la petición:
8. Conclusiones
En este artículo se puede ver lo fácil que es instalar la herramienta soapUI y la rapidez con la que se puede empezar a utilizar.
Además, como hemos visto, posee licencia opensource y es por lo tanto gratuita.
Hemos visto ejemplos enfocados a realizar pruebas funcionales unitarias de los distintos métodos HTTP (Get, Post, Put, Delete) para la verificación de un servicio REST API de un dominio web, que es un buen ejemplo inicial de las posibilidades que nos ofrece la herramienta soapUI.
Aún podemos aumentar el nivel de pruebas sobre el servicio REST API con dicha herramienta, automatizando dichas pruebas haciendo uso de la utilidad de generar una suite de pruebas e insertando en ella casos de pruebas, aserciones, etc. , aunque esto será material para un futuro artículo.
Si te ha gustado, ¡síguenos en Twitter para próximos posts!