Mocks, stubs, fakes et émulateurs : test des appels d’API avec des agents de codage

Lorsque votre code appelle une API, vous avez besoin d’un moyen de le tester sans attendre que l’API réelle échoue. Vous avez 5 types de stand-ins à choisir. Les utilisateurs utilisent les noms librement. Voici comment cet article les utilise :

  • Stub : remplacement in-process de votre client HTTP ou de votre appel SDK qui retourne une réponse prédéfinie. Il est rapide et reproductible, et il teste votre logique pour la réponse que vous avez écrite.
  • Mock : stub qui enregistre également la façon dont votre code l’a appelé, afin que votre test puisse vérifier les appels. Il atteint jusqu’à un tronçon.
  • Serveur simulé : un petit serveur opérationnel, souvent en mémoire, que votre application appelle via HTTP au lieu de l’API réelle. Il teste votre client HTTP, mais vous devez configurer votre application pour utiliser son URL.
  • Émulateur : version locale d’un service, généralement publiée par le propriétaire du service, qui se comporte comme le service réel pour les opérations qu’il prend en charge. Vérifiez les limites et les défaillances qu’il couvre avant de vous appuyer sur celui-ci pour la gestion des erreurs.
  • Proxy d’interception : se trouve sur le réseau entre votre application et l’API. Votre application appelle l’URL réelle, et le proxy transmet les requêtes telles quelles ou répond à certaines d’entre elles avec la réponse que vous définissez. Votre application doit envoyer son trafic via le proxy et, pour HTTPS, faire confiance au certificat du proxy.

Guide pratique pour tester le code qui appelle une API

Approach Ce qu’il teste Ce dont il a besoin Juste au moment où
Stub ou mock Votre logique pour une réponse spécifique Votre framework de test Vous testez la logique métier, l’analyse et les branches d’erreur dans les tests unitaires
Serveur factice Votre client HTTP et votre sérialisation Paramètre d’URL de base ou commutateur de configuration dans votre application L’API n’existe pas encore, ou vous aurez besoin d’un back-end stable pour le travail de l’interface utilisateur
Émulateur Comportement proche du service réel pour les opérations prises en charge Un autre point de terminaison ou chaîne de connexion Le propriétaire du service en livre un et vous développez hors connexion
API réelle avec un compte de test L’original Identifiants, quota et argent Vous vérifiez le chemin principal de bout en bout
Proxy d’interception Votre application s’exécutant sur des URL réelles, y compris les nouvelles tentatives du SDK et les en-têtes de réponse Paramètres de proxy et confiance du certificat Vous testez les défaillances, les limites et la latence sans modifier votre application

Vous avez besoin de plus de 1 de ces éléments. Les stubs permettent d’exécuter rapidement vos tests unitaires. Un proxy vous montre ce que fait l’ensemble de l’application lorsque l’API réelle se comporte mal. Pour plus d’informations sur la façon dont les 2 s’intègrent, consultez Dev Proxy vs tests unitaires.

Ce que créent les agents de codage

Lorsque vous demandez à un agent de programmation de gérer les échecs d’API de votre application et de prouver que cela fonctionne, il choisit un substitut pour vous. Nous voulions savoir lequel, donc, nous avons exécuté un test avec 3 agents de codage (210 exécutions). Les tâches ont utilisé des formulations telles que « gérer correctement la limitation du débit et me montrer que cela fonctionne », « la vérifier sans dépenser d’argent pour de véritables appels d’API » et « l’exécuter sans clé OpenAI ni connexion Internet ».

  • Dans 76 % des 140 essais où du code fonctionnel était demandé, l’agent a recréé manuellement la défaillance : des stubs de requête fetch, httpx.MockTransport, ou un serveur HTTP temporaire.
  • Dans 61 des 105 exécutions d’applications qui appellent GitHub, OpenAI ou une API météo, l’agent a ajouté une URL de base ou un commutateur de configuration à l’application afin qu’elle puisse accéder à son faux service.
  • Dans les 75 exécutions où l’API réelle était disponible et l’invite ne l’a pas exclu, 0 a testé l’application sur son URL d’API réelle.

Les stubs sont un choix raisonnable pour les tests unitaires. L’écart est ce qu’ils omettent. Le stub de l’agent retourne l’erreur attendue par l’agent, ce qui peut ne pas correspondre à ce que l’API envoie. Et l’option qu’il a ajoutée pour atteindre les appareils factices avec votre application.

Comment travailler avec les tests de votre agent

  • Conservez les stubs pour votre logique. Ils sont rapides et testent les branches écrites par l’agent.
  • Demandez le format d’erreur réel. Demandez à l’agent de baser chaque erreur simulée sur les codes d’état, les en-têtes et les champs du corps documentés du fournisseur. Un simple code 429 ne vérifie pas si votre application interprète retry-after ou fait la différence entre une erreur de facturation et une limitation de débit.
  • Passez en revue les changements ajoutés pour les tests. Si l’agent ajoute un paramètre d’URL de base uniquement afin que les tests puissent accéder à un faux service, déterminez si vous souhaitez ce paramètre dans votre code de production.
  • Exécutez l’application une fois sur des URL réelles avec des échecs simulés. Avant de publier, vérifiez ce que l’application en cours d’exécution, son SDK et sa stratégie de réessai font avec les erreurs de l’API. Pour passer en revue la gestion des erreurs de l’agent étape par étape, consultez Comment vérifier la gestion des erreurs que votre agent de codage a écrit.

Essayez-le dans votre application

Dev Proxy est un proxy d’interception pour le développement. Elle retourne les réponses que vous définissez pour les URL que votre application appelle déjà, sans aucune modification du code de votre application. Activez MockResponsePlugin dans votre configuration : 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"
  }
}

Définissez ensuite la réponse dans mocks.json. Celle-ci retourne 503 avec un Retry-After en-tête pour le point de terminaison de prévision :

{
  "$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"
        }
      }
    }
  ]
}

Démarrez le proxy de développement et exécutez votre application comme d’habitude :

devproxy --config-file devproxyrc.json

Les demandes qui ne correspondent pas à une simulation vont à l’API réelle. Quand vous avez besoin d’un back-end qui n’existe pas encore, CrudApiPlugin simule une API CRUD avec des données en mémoire. Pour faire échouer une partie des requêtes de façon aléatoire plutôt qu'à chaque fois, consultez Tester mon application avec des erreurs aléatoires. Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étapes suivantes

Simuler des réponses

Voir aussi

  • Dernière mise à jour :