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: reemplazo en el proceso de tu cliente HTTP o de tu llamada al SDK que devuelve una respuesta predefinida. Es rápido y repetible, y prueba la lógica de la respuesta que escribiste.
  • Mock: código auxiliar que también registra cómo lo llamó el código, por lo que la prueba puede comprobar las llamadas. Llega hasta el extremo de un código auxiliar.
  • Servidor falso: un servidor de trabajo pequeño, a menudo en memoria, al que tu aplicación llama a través de HTTP en lugar de la API real. Ejecuta el cliente HTTP, pero tiene que apuntar la aplicación en su dirección 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. Compruebe qué límites y errores cubre antes de confiar en él para el control de errores.
  • Interceptar proxy: se encuentra en la red entre la aplicación y la API. La aplicación llama a la dirección URL real y el proxy reenvía las solicitudes o responde a algunas de ellas con la respuesta que defina. La aplicación tiene que enviar su tráfico a través del proxy y, para HTTPS, confiar en el certificado del proxy.

Prueba del 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 Su entorno de pruebas Pruebas la lógica de negocios, el análisis y las ramas de errores en las 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 envía uno 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 en funcionamiento en direcciones URL reales, incluidos los reintentos del SDK y los encabezados de respuesta Configuración de proxy y confianza de certificados Prueba de errores, límites y latencia sin cambiar la aplicación

Necesita más de 1 de estos. Los códigos auxiliares mantienen las pruebas unitarias rápidas. 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é agentes de codificación se compilan

Cuando se pide a un agente de codificación que haga que la aplicación controle los errores de API y muestre que funciona, elige un stand-in automáticamente. Queríamos saber cuál, por lo que ejecutamos una prueba con 3 agentes de codificación (210 ejecuciones). Las tareas que se usan expresiones como "controlar la limitación de velocidad correctamente y mostrarme que funciona", "comprobarlo sin gastar dinero en llamadas API reales" y "ejecutar esto sin una clave de OpenAI o una conexión a Internet".

  • En 76% de las 140 ejecuciones que solicitaron código de trabajo, el agente creó el error manualmente: capturar códigos auxiliares, httpx.MockTransporto un servidor HTTP desuso.
  • En el 61 de los 105 se ejecuta en aplicaciones que llaman a GitHub, OpenAI o una API meteorológica, el agente agregó una dirección URL base o un modificador de configuración a la aplicación para que pudiera llegar a su falso.
  • En las 75 ejecuciones en las que la API real estaba disponible y la instrucción no lo descartaba, 0 probó la aplicación en su URL real de la API.

Los stubs son una opción razonable para las pruebas unitarias. La diferencia está en lo que omiten. El código auxiliar del agente devuelve el error esperado por el agente, que podría no coincidir con lo que envía la API. Y el selector que añadió para acceder a los barcos falsos desde la aplicación.

Cómo trabajar con las pruebas de tu agente

  • Mantener los stubs para su 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 prueba que la aplicación lee retry-after o distingue un error de facturación de un límite de tasa.
  • Revise los interruptores agregados para las pruebas. Si el agente agrega una configuración de URL base solo para que las pruebas puedan acceder a un servicio simulado, decida si desea esa configuración en el código de producción.
  • Ejecute la aplicación una vez en direcciones URL reales con errores simulados. Antes de publicar, compruebe lo que hace la aplicación en ejecución, su SDK y su directiva de reintento con los propios errores de la API. Para revisar el control de errores del agente paso a paso, consulte Cómo comprobar el control de errores que escribió el agente de programación.

Pruébelo en la 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. Activa MockResponsePlugin en tu config, 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 Retry-After encabezado 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