Simula tus pruebas de UI con Wiremock

Inconvenientes del entorno

La fiabilidad de las pruebas automatizadas debe ser uno de los puntos más importantes a tener en cuenta cuando decidimos llevar la automatización a nuestro proyecto. Para obtener un resultado real de la ejecución de nuestras pruebas, es imprescindible que el entorno donde se lancen esté lo más controlado posible. Un entorno inestable puede hacer que el número de falsos negativos aumente considerablemente y que los fallos detectados no sean problemas reales en el código de la aplicación. Por tanto, nuestras pruebas dejarían de ser fiables, el proceso de depuración sería más costoso y perderían su función principal. Hay varios factores por los que podemos considerar que el entorno de pruebas no es estable:

• No hay control sobre la base de datos y no hay un estado inicial o un reinicio después de las modificaciones producidas por las pruebas automáticas.
• No está dedicado exclusivamente a las pruebas automatizadas, por lo que los datos pueden ser modificados por los desarrolladores u otros perfiles.
• Hay despliegues incontrolados en el entorno que pueden provocar una caída temporal de los servicios.
• Existen dependencias con otros servicios externos no controlados por nuestro producto.
• La infraestructura es inestable en cuanto a recursos y produce colisiones espontáneas.

Si detectamos alguno de los puntos descritos anteriormente, debemos considerar la implementación de la solución Wiremock.

Wiremock: Ventajas y capacidades

Wiremock es un servidor de simulacros HTTP, que funciona no sólo como un servidor que sirve respuestas simuladas a una app cliente, sino que también funciona como un proxy en la comunicación entre la app cliente y el servidor de la API, pudiendo así registrar las peticiones y respuestas generadas en la comunicación para generar mapeos que posteriormente servirán como mocks para la aplicación.

Para ello, Wiremock puede configurarse como un elemento independiente en la comunicación entre la app cliente y la API o cómo un proceso que puede ejecutarse en un test automatizado utilizando la propia librería Wiremock. En ambos casos, Wiremock se mantendrá como un elemento receptor a la espera de recibir llamadas para servir como mocks. Al configurarse como proxy, Wiremock reenviará la petición realizada por la app a la API, para que ésta devuelva la respuesta esperada, Wiremock registrará la información recibida de la API con la que generará un mapeo. Este mapeo nos ayudará a configurar el mock de una forma mucho más fácil y sencilla.

Configuración de Wiremock

Proceso autónomo

1. Descarga el archivo .JAR del sitio web de Wiremock
2. Inicia el proceso con el comando en el terminal

cd folder/with/wiremock_jar
java -jar wiremock-jre8-standalone-2.33.2.jar

El servidor estará accesible en http://localhost:8080__admin por defecto.

Ejecución en código

Implementa Wiremock en Gradle y establece la configuración:

implementation("com.github.tomakehurst:wiremock-jre8-standalone:2.33.2")

private val mainResourcePath = System.getProperty("user.dir") + "/src/test/resources"
private val wireMockServer = WireMockServer(options().port(8080).usingFilesUnderDirectory(mainResourcePath))

Inicia y detén el servidor con wiremockServer.start() y wiremockServer.stop()

Asignaciones de registros

Para registrar todos los mapeos en Wiremock se debe habilitar la configuración del proxy, ya sea si se ejecuta Wiremock como un proceso independiente o se está ejecutando a través de código.

Se recomienda su uso como proceso independiente.

java -jar wiremock-jre8-standalone-2.33.2.jar --proxy-all="URL" --record-mappings

También existe la posibilidad de ejecutar el wiremock como standalone sin las banderas proxy-all y record-mappings y configurar la grabación a través de la siguiente URL: http://localhost:8080/__admin/recorder/

Una vez que Wiremock esté funcionando y los endpoints estén siendo llamados se generarán archivos JSON bajo una carpeta de mappings con esta estructura similar (el nombre puede ser formateado).

Este archivo ya contiene la información necesaria para crear el talón falso, podemos actualizar la información a nuestro gusto.

{
  "id" : "91555df1-f6de-44bc-a3c6-8cb6dab34728",
  "name" : "v2_user_login",
  "request" : {
    "url" : "/v2/user/login?disableCaptcha",
    "method" : "POST",
    "bodyPatterns" : [ {
      "equalToJson" : "{\"device_id\":\"${json-unit.any-string}\",\"device_model\":\"${json-unit.any-string}\",\"device_type\":\"phone\",\"email\":\"[email protected]\",\"g-recaptcha-response\":\"test\",\"is_app\":true,\"os\":\"Android\",\"os_version\":\"${json-unit.any-string}\",\"password\":\"Test1313??\",\"version\":\"${json-unit.any-string}\"}",
      "ignoreArrayOrder" : true,
      "ignoreExtraElements" : true
    } ]
  },
  "response" : {
    "status" : 200,
    "body" : "{\"data\":{\"type\":\"user_session\",\"attributes\":{\"language\":\"eng\",\"currency\":\"EUR\",\"id\":\"d0fbaf4f-65b7-4950-b883-6a2129f1fe42\"}}",
    "headers" : {
      "Date" : "Wed, 08 Jun 2022 09:32:21 GMT",
      "Content-Type" : "application/json",
      "Access-Control-Allow-Origin" : "*",
      "Access-Control-Allow-Headers" : "origin, content-type, access-token, x-tracking-id, bp-client, If-None-Match, If-Match",
      "Cache-Control" : "no-store, private",
      "X-RateLimit-Limit" : "100",
      "Strict-Transport-Security" : "max-age=31536000; includeSubDomains",
      "X-Frame-Options" : "SAMEORIGIN",
      "CF-Cache-Status" : "DYNAMIC",
      "Expect-CT" : "max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\"",
      "Server" : "cloudflare",
      "CF-RAY" : "71809ea78a26958d-DUB"
    }
  },
  "uuid" : "91555df1-f6de-44bc-a3c6-8cb6dab34728",
  "persistent" : true,
  "insertionIndex" : 42
}

La imitación del mapeo registrado con el correo electrónico y la respuesta permite crear flujos controlados en la aplicación para probar los escenarios.

${json-unit.regex} nos permite incluir cualquier cadena como válida para que coincida con la petición-respuesta esperada en el mapeo.

Android

El único requisito es asegurarse de que la aplicación está conectada a la dirección IP y al puerto del servidor Wiremock (ver BASE_URL) en el archivo build.gradle de la aplicación. Considerando 192.168.0.18:8080 como la dirección IP y el puerto de Wiremock es todo lo que se necesita para que Wiremock sirva mocks a la app. En el caso de que Wiremock funcione como proxy en la comunicación, la herramienta debe estar configurada con esta configuración –proxy-all=»URL_OF_API_SERVICE».

iOS

Al igual que en Android, tenemos que conectar la aplicación con la dirección IP y el puerto del servidor Wiremock (ver APP_BASE_URL) en el archivo de configuración de la aplicación. Considerando 192.168.0.20:8080 como la IP.

Conclusión

Ante la problemática de las empresas actuales de disponer de entornos dedicados a las pruebas y que permitan ejecutar las pruebas de UI de forma consistente y aislada del resto de factores ajenos al código de la aplicación, el uso de mocks para la ejecución de las pruebas de UI ha demostrado ser una solución fiable. Wiremock nos permite registrar la comunicación entre la app y la API para generar mapeos que finalmente funcionarán como stubs para servir a la aplicación las mismas respuestas para cada escenario que se lance en el test, de forma que los resultados de cada test de UI sólo dependerán de un único factor: el código.