Mocks, stubs, fakes y emuladores: probar llamadas API con agentes de codificación

Cuando el código llama a una API, necesita una manera de probarla sin esperar a que se produzca un error en la API real. Tiene 5 tipos de stand-ins entre los que elegir. Los usuarios usan los nombres de forma flexible, por lo que aquí se explica cómo los usa este artículo:

  • Stub: un sustituto dentro del proceso para tu cliente HTTP o llamada al SDK que devuelve una respuesta predefinida. Es rápido y repetible, y comprueba tu lógica en relación con la respuesta que has escrito.
  • Mock: un stub que además registra cómo lo ha llamado tu código, para que tu prueba pueda comprobar las llamadas. Su alcance es el mismo que el de un stub.
  • Servidor falso: un pequeño servidor operativo, a menudo en memoria, al que tu aplicación llama a través de HTTP en lugar de a la API real. Pone a prueba tu cliente HTTP, pero tienes que configurar tu aplicación para que apunte a su URL.
  • Emulador: una versión local de un servicio, normalmente publicada por el propietario del servicio, que se comporta como la real para las operaciones que admite. Comprueba qué límites y fallos cubre antes de confiar en él para la administración de errores.
  • Proxy de interceptación: se sitúa en la red entre tu aplicación y la API. Tu aplicación llama a la URL real, y el proxy deja pasar las solicitudes o responde a algunas de ellas con la respuesta que tú definas. La aplicación tiene que enviar su tráfico a través del proxy y, para HTTPS, confiar en el certificado del proxy.

Cómo probar el código que llama a una API

Approach Qué prueba Lo que necesita Justo cuando
Stub o mock Tu lógica para una respuesta específica Tu marco de pruebas Probas la lógica de negocio, el análisis sintáctico y las ramas de error en pruebas unitarias
Servidor falso Tu cliente HTTP y la serialización Una configuración de dirección URL base o un modificador de configuración en la aplicación La API aún no existe o se necesita un back-end estable para el trabajo de la interfaz de usuario.
Emulador Comportamiento cercano al servicio real para las operaciones admitidas Un punto de conexión o cadena de conexión diferente El propietario del servicio lo pone en producción y tú desarrollas sin conexión
API real con una cuenta de prueba Lo auténtico Credenciales, cuota y dinero Compruebe la ruta de acceso principal de un extremo a otro.
Proxy de interceptación Tu aplicación se ejecuta en URL reales, incluyendo reintentos del SDK y encabezados de respuesta Configuración de proxy y confianza de certificados Pruebas los fallos, los límites y la latencia sin modificar tu aplicación

Necesita más de 1 de estos. Los stubs mantienen la rapidez de tus pruebas unitarias. Un proxy muestra lo que hace toda la aplicación cuando la API real se comporta mal. Para obtener más información sobre cómo encajan las 2 juntas, consulte Dev Proxy frente a las pruebas unitarias.

Qué crean los agentes de programación

Cuando le pides a un agente de programación que haga que tu aplicación administre los fallos de la API y demuestre que funciona, este elige un sustituto por ti. Queríamos saber cuál, por lo que ejecutamos una prueba con 3 agentes de codificación (210 ejecuciones). Las tareas incluían formulaciones como "administra correctamente la limitación de tasa y demuéstrame que funciona", "verifícalo sin gastar dinero en llamadas reales a la API" y "ejecuta esto sin una clave de OpenAI ni conexión a Internet".

  • En el 76 % de las 140 ejecuciones en las que se solicitaba código funcional, el agente creó el fallo manualmente: stubs de recuperación, httpx.MockTransport o un servidor HTTP temporal.
  • En 61 de las 105 ejecuciones en aplicaciones que llaman a GitHub, OpenAI o una API meteorológica, el agente añadió una URL base o un parámetro de configuración a la aplicación para que pudiera acceder a su versión falsa.
  • En las 75 ejecuciones en las que la API real estaba disponible y la indicación no la descartaba, ninguno probó la aplicación en su URL de API real.

Los stubs son una opción razonable para las pruebas unitarias. La diferencia radica en lo que omiten. El stub del agente devuelve el error que este esperaba, lo que puede no coincidir con lo que envía la API. Y el parámetro que añadió para acceder al simulador se incluye en tu aplicación.

Cómo trabajar con las pruebas de tu agente

  • Mantén los stubs para tu lógica. Son rápidos y prueban las ramas que escribió el agente.
  • Solicite el formato real del error. Pida al agente que base cada error simulado en los códigos de estado, encabezados y campos del cuerpo documentados del proveedor. Un simple 429 no comprueba que tu aplicación lea retry-after ni distinga un error de facturación de un límite de rate.
  • Revisa los parámetros añadidos para las pruebas. Si el agente añade una configuración de URL base únicamente para que las pruebas puedan acceder a un simulador, decide si quieres esa configuración en tu código de producción.
  • Ejecuta la aplicación una vez en URL reales con fallos simulados. Antes de lanzarla, comprueba cómo administran la aplicación en ejecución, su SDK y su directiva de reintentos los propios errores de la API. Para revisar paso a paso la administración de errores del agente, consulta Cómo verificar la administración de errores que ha escrito tu agente de programación.

Pruébalo en tu aplicación

Dev Proxy es un proxy de interceptación para el desarrollo. Devuelve las respuestas que defines para las direcciones URL a las que la aplicación ya llama, sin cambios en el código de la aplicación. Habilita el MockResponsePlugin en tu configuración, devproxyrc.json:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "MockResponsePlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "mocksPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.contoso.com/*"
  ],
  "mocksPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.schema.json",
    "mocksFile": "mocks.json"
  }
}

A continuación, defina la respuesta en mocks.json. Este devuelve 503 con un encabezado Retry-After para el punto de conexión de previsión:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.mocksfile.schema.json",
  "mocks": [
    {
      "request": {
        "url": "https://api.contoso.com/v1/forecast*",
        "method": "GET"
      },
      "response": {
        "statusCode": 503,
        "headers": [
          {
            "name": "Retry-After",
            "value": "10"
          }
        ],
        "body": {
          "error": "Service unavailable"
        }
      }
    }
  ]
}

Inicie el proxy de desarrollo y ejecute la aplicación como de costumbre:

devproxy --config-file devproxyrc.json

Las solicitudes que no coinciden con una simulación van a la API real. Cuando necesite un back-end que aún no exista, CrudApiPlugin simula una API CRUD con datos en memoria. Para hacer fallar aleatoriamente una parte de las solicitudes en lugar de hacerlo siempre, consulta Probar mi aplicación con errores aleatorios. Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Pasos siguientes

Respuestas ficticias

Consulte también

  • Se actualizó por última vez el