Acceso a Datos

2º DAM - Curso 2023-2024

User Tools

Site Tools


apuntes:api-sandbox

API Sandbox

WireMock

WireMock es una herramienta para la creación de APIs virtuales o APIs Mock. Permite definir los casos de prueba (de éxito y fallo) y las respuesta asociadas a éstos.

Definir los casos de prueba

Los casos de prueba deberán ser tanto de éxito como de fallo, lo que se conocen como casos OK y casos KO.

A continuación vamos a ver cómo preparar un caso de cada tipo:

POST /products - OK 201

En este caso se trata de mockear el caso de éxito del registro de un producto. El primer fichero, el de mapeo, define la petición que define dicho caso:

  • Método: POST
  • URL del endpoint: /products
  • Código de estado de respuesta: 201
  • Tipo de dato de la respuesta: application/json
  • Cuerpo de respuesta: Es otro fichero que contendrá la respuesta de esta operación
mappings/postProducts-ok.json
{
  "request": {
    "method": "POST",
    "url": "/products"
  },
  "response": {
    "status": 201,
    "headers": {
      "Content-Type": "application/json"
    },
    "bodyFileName": "postProducts-ok.json"
  }
}

Asi, a continuación, definimos el fichero que contiene la respuesta mockeada para esta operación:

__files/postProducts-ok.json
{
  "id": 24,
  "name": "Butter",
  "description": "Salted butter",
  "category": "Food",
  "price": 8.45,
  "creationDate": "2023-01-03"
}

DELETE /product/{productId} - KO 404

En este caso, como caso de KO, pretendemos mockear una operación de borrado que acaba fallando. Asi, definimos la operación que eliminaría el producto cuyo id = 12.

Definimos el fichero de mapeo como priority: 2 puesto que es fácil que hayamos definido antes una operación más genérica para el caso de borrado de éxito. Necesitamos que esta operación tenga prioridad sobre cualquier otra cuyo mapeo pueda coincidir. Asi, podremos definir casos de éxito para cualquiera id excepto para el id=12 que será nuestro caso de fallo.

mappings/deleteProduct-ko-404.json
{
  "priority": 1,
  "request": {
    "method": "DELETE",
    "url": "/product/12"
  },
  "response": {
    "status": 404,
    "headers": {
      "Content-Type": "application/json"
    },
    "bodyFileName": "deleteProduct-ko-404.json"
  }
}

Y en el cuerpo de la respuesta definimos el contenido de la respuesta para este caso de fallo:

__files/deleteProduct-ko-404.json
{
  "internalError": 1,
  "message": "No se ha podido encontrar el producto"
}

El fichero de mapeo que podríamos tener preparado para el caso de éxito de esta operación, sería como se muestra a continuación. En este caso no priorizaríamos el caso y además utilizaremos el atributo urlPattern para generalizar la URL. Como resultado, con ambos casos KO y KO, tendremos un caso OK para cualquier id excepto para el id 12 que será definido como caso de fallo (con un valor de id concreto y priorizado para ser siempre evaluado primero en caso de coincidencia con otros casos)

mappings/deleteProduct-ok-204.json
{
  "request": {
    "method": "DELETE",
    "urlPattern": "/product/.*"
  },
  "response": {
    "status": 204,
    "headers":{
      "Content-Type": "application/json"
    }
  }
}

Lanzar la API sandbox

Una vez que tengamos todos los casos de prueba (mappings) y sus ficheros de respuesta asociados (files), podemos lanzar nuestra API mock con el siguiente comando:

santi@zenbook:$ java -jar wiremock-jre8-standalone-2.32.0.jar

En el repositorio de proyectos spring-web hay un ejemplo de Proyecto de una API Mock con diferentes casos OK y KO.


© 2022-2024 Santiago Faci

apuntes/api-sandbox.txt · Last modified: 31/03/2024 17:50 by Santiago Faci