eyeglasses-679696_640

Todos sabemos de la importancia de probar un software, pero en el caso de los servicios, yo diría que esto es más crítico aún. Lo digo entre otras cosas porque normalmente un servicio que desarrollemos ahora, lo va a consumir una tercera persona, quizás incluso fuera de la empresa, e incluso, semanas o meses después de que lo hayamos publicado.

Tipos de pruebas hay muchos, desde las pruebas unitarias, pruebas de regresión, pruebas de integración, etc. etc. Pues bien, entiendo que las pruebas unitarias las tiene que hacer el propio desarrollador por lo que, en este caso, me quiero referir a las pruebas de integración y de regresión de servicios web.

Por pruebas de integración entiendo el tener un “cliente” que haga las invocaciones a los servicios con un mensaje de pruebas adecuado y validar la respuesta del mensaje. Por pruebas de regresión, a aquellas pruebas destinadas a  garantizar que no hayamos roto nada de lo que ya funcionaba cuando hacemos un cambio en el software.

Por terminar el listado de necesidades en el caso del desarrollo de servicios REST, nos encontramos con que tenemos que documentar o describir el contrato de los servicios para comunicar a otra persona cómo debe invocar a los servicios. Como no tenemos un estándar bien implantado como es el caso de los WSDL en SOAP, en REST podemos optar por varias alternativas como swagger, RAML, etc. Pero también está el más extendido, creo yo, que el hacer un simple documento word con ejemplos de mensajes de entrada/salida, códigos http devueltos, etc. etc.

Así pues, resumiendo, ¿Por qué no tener una herramienta capaz de hacer estas pruebas de integración, pruebas de regresión, y de paso, documentar el contrato de los servicios a base de ejemplos reales de ejecución?.

La “herramienta”

Pues nada, como precisamente estoy inmerso en el desarrollo de un proyecto con servicios REST del que os hablaré más adelante en otra entrada del blog con todo lujo de detalles ;-), me he puesto a “fabricarme” esta herramienta.

Lo primero que se necesita es un componente que te haga todo el trabajo sucio de invocación por HTTP y que sea capaz de enviar peticiones por GET, POST y lo que sea menester… investigando un poco he dado con este Server Driver que es capaz también de procesar los mensajes en JSON.

Este es un ejemplo de invocación:

Response response = post(BASE_URL + /things, body(someJson, application/json));

Casos de uso

Por supuesto, existen otras herramientas como Postman que pueden servir perfectamente para hacer invocaciones aisladas al servidor y probar el servicio. Sin embargo, cuando lo que queremos probar es todo un caso de uso como por ejemplo:

  1. crear un usuario o cliente
  2. confirmar el cliente
  3. hacer login con este cliente
  4. consultar cliente
  5. modificar cliente
  6. borrar cliente
  7. consultar el mismo cliente y comprobar que ya no existe
  8. etc.

Además, para complicar más las cosas, hay información (campos de vuelta normalmente) que se necesitan de un paso para otro.

Por ejemplo, el servicio de crear un cliente te devuelve un id del cliente. Ese id del cliente se necesita obviamente para después consultarlo. Así pues, necesitamos una especie de “memoria” o de “contexto” de la misma manera que el frontal (por ejemplo construido en HTML5) guardaría esta información en una variable para enviarla posteriormente.

Para esta herramienta, un simple objeto “Map” donde se guarden pares del tipo clave-valor será más que suficiente.

Con todo esto, y en la línea de lo que hace JUnit, podremos poner comprobaciones para validar que las invocaciones han ido como se esperaban. Por ejemplo, que obtengamos un código http 200 y no un 500.

Captura de pantalla 2015-10-06 a las 22.40.20

Documentarlo

La otra pata que nos falta en la herramienta es la documentación. Pues bien, aquí lo que hago sencillamente es que en le método que hace las llamadas se escribe en un fichero (en formato MarkDown para que mole más) las invocaciones que se hacen con una etiqueta para identificarlo, el método que se usa (GET, POST, …), la URI, el mensaje de entrada, el de salida y el código HTTP.

Algo como esto:

Captura de pantalla 2015-10-06 a las 22.36.27

En definitiva, creo que me he hecho una herramienta sencilla y potente para hacer pruebas de servicios REST, sobre todo nuestras queridas pruebas de regresión para ver que no hemos roto nada.  Y a la vez dejar “constancia” del interfaz de los mismos, es decir, de los contratos.

Esta herramienta, que todavía no tiene nombre 😉 la subiré a Github por si queréis echarle un vistazo.

¿y tú? ¿usas alguna herramienta de este estilo? ¿cuál?

Anuncios