mocks, stubs, fakes e emuladores: testando chamadas à API com agentes de codificação

Quando o código chama uma API, você precisa de uma maneira de testá-la sem esperar que a API real falhe. Você tem cinco tipos de stand-ins para escolher. As pessoas usam os nomes livremente, portanto, veja como este artigo os usa:

  • Stub: uma substituição no mesmo processo para seu cliente HTTP ou chamada do SDK que retorna uma resposta predefinida. É rápido e repetível, e testa sua lógica na resposta que você escreveu.
  • Mock: um stub que também registra como seu código o chamou, para que seu teste possa verificar as chamadas. Ele chega até uma extremidade sem saída.
  • Servidor falso: um servidor funcional pequeno, muitas vezes na memória, que seu aplicativo chama por HTTP em vez da API real. Ele testa seu cliente HTTP, mas você precisa apontar seu aplicativo para a URL dele.
  • Emulador: uma versão local de um serviço, geralmente publicada pelo proprietário do serviço, que se comporta como a real para as operações compatíveis. Verifique quais limites e falhas ele cobre antes de você contar com ele para tratamento de erros.
  • Proxy de interceptação: fica na rede entre seu aplicativo e a API. Seu aplicativo chama a URL real, e o proxy encaminha as solicitações ou responde a algumas delas com a resposta que você define. Seu aplicativo precisa enviar seu tráfego por meio do proxy e, para HTTPS, confiar no certificado do proxy.

Como testar o código que chama uma API

Approach O que ele testa O que é necessário Justo quando
Stub ou mock Sua lógica para uma resposta específica Seu framework de teste Você testa a lógica de negócios, o parsing e os branches de erro em testes de unidade
Servidor falso Seu cliente HTTP e sua serialização Uma opção de configuração ou configuração de URL base em seu aplicativo A API ainda não existe ou você precisa de um back-end estável para o trabalho da interface do usuário
Emulator Comportamento próximo ao serviço real para operações com suporte Um ponto de extremidade ou cadeia de conexão diferente O proprietário do serviço envia um e você desenvolve offline
API real com uma conta de teste O verdadeiro Credenciais, cota e dinheiro Você verifica o caminho principal de ponta a ponta
Proxy de interceptação Seu aplicativo sendo executado em URLs reais, incluindo tentativas do SDK e cabeçalhos de resposta Configurações de proxy e confiança do certificado Você testa falhas, limites e latência sem alterar seu aplicativo

Você precisa de mais de um destes. Os stubs mantêm os testes de unidade rápidos. Um proxy mostra o que todo o aplicativo faz quando a API real se comporta mal. Para obter mais informações sobre como os 2 se encaixam, consulte Dev Proxy versus testes de unidade.

O que os agentes de codificação criam

Quando você pede a um agente de codificação para fazer seu aplicativo lidar com falhas de API e mostrar que ele funciona, ele escolhe um stand-in para você. Queríamos saber qual deles, então executamos um teste com 3 agentes de codificação (210 execuções). As tarefas usavam frases como "manipular a limitação de taxa corretamente e mostrar que ela funciona", "verificar sem gastar dinheiro em chamadas de API reais" e "executar isso sem uma chave OpenAI ou uma conexão com a Internet".

  • Em 76% das 140 execuções que solicitaram código funcional, o agente criou a falha manualmente: stubs de fetch, httpx.MockTransport ou um servidor HTTP descartável.
  • Em 61 das 105 execuções em aplicativos que chamam GitHub, OpenAI ou uma API meteorológica, o agente adicionou uma URL base ou uma opção de configuração ao aplicativo para que ele pudesse acessar sua versão simulada.
  • Nas 75 execuções em que a API real estava disponível e o prompt não a excluiu, 0 testaram o aplicativo em sua URL de API real.

Stubs são uma opção razoável para testes de unidade. A lacuna é o que eles deixam de fora. O stub do agente retorna o erro esperado pelo agente, que pode não corresponder ao que a API envia. E a chave que ele adicionou para acessar as naves falsas com seu aplicativo.

Como trabalhar com os testes do seu agente

  • Mantenha os stubs para sua lógica. Eles são rápidos e testam as branches que o agente escreveu.
  • Peça o formato real do erro. Peça ao agente para basear cada erro simulado nos códigos de status documentados, cabeçalhos e campos do corpo do provedor. Um 429 nu não testa se seu aplicativo lê retry-after ou distingue um erro de cobrança de um limite de taxa.
  • Revise os interruptores adicionados para testes. Se o agente adicionar apenas uma configuração de URL base para que os testes possam alcançar um falso, decida se você deseja essa configuração no código de produção.
  • Execute o aplicativo uma vez em URLs reais com falhas simuladas. Antes de enviar, verifique o que o aplicativo em execução, seu SDK e sua política de repetição fazem com os próprios erros da API. Para examinar o tratamento de erros do agente passo a passo, confira Como verificar o erro ao lidar com o agente de codificação.

Experimente em seu aplicativo

O Proxy de Desenvolvimento é um proxy de interceptação para desenvolvimento. Ele retorna as respostas que você define para as URLs às quais seu aplicativo já faz chamadas, sem alterações no código do aplicativo. Habilite o MockResponsePlugin na configuração: 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"
  }
}

Em seguida, defina a resposta em mocks.json. Retorna 503 com um cabeçalho Retry-After para o endpoint de previsão:

{
  "$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 o Proxy de Desenvolvimento e execute seu aplicativo como de costume:

devproxy --config-file devproxyrc.json

Solicitações que não correspondem a um mock vão para a API real. Quando você precisa de um back-end que ainda não existe, o CrudApiPlugin simula uma API CRUD com dados na memória. Para falhar uma parte das solicitações aleatoriamente em vez de todas as vezes, consulte Testar meu aplicativo com erros aleatórios. Para instalar o Dev Proxy, consulte Configurar o Dev Proxy.

Próximas Etapas 

Consulte também