Tester l'API Claude Fable 5.2 avec Apidog : tests de régression

Pour tester les intégrations de l'API Claude Fable 5.2, validez l'authentification, le corps de la requête Messages, les blocs de réponse typés et les échecs prévisibles. Enregistrez ensuite ces vérifications sous forme de cas de test Apidog répétables que votre agent de codage exécute via la CLI. Séparez les assertions de transport des vérifications de qualité de tâche, afin qu'une réponse HTTP réussie ne puisse pas masquer une réponse inutilisable.

L'annonce d'Anthropic identifie claude-fable-5-2 comme l'ID de modèle de la plateforme Claude. Ce guide construit un workflow de régression autour de ce modèle, plutôt que de s'arrêter après une seule réponse réussie. Apidog offre à votre agent un espace partagé pour maintenir le point de terminaison, les cas de test et les rapports d'exécution.

Que doivent couvrir les tests de l'API Claude Fable 5.2 ?

Utilisez trois couches : les vérifications de transport établissent si la requête a atteint le service ; les vérifications de contrat valident la structure de la réponse ; les vérifications comportementales établissent si votre application peut utiliser le résultat. Exécutez les deux premières pour chaque fixture. Définissez des critères d'acceptation comportementale pour chaque tâche au lieu de comparer des réponses générées complètes octet par octet.

Commencez avec une fixture minuscule et inoffensive : « Combien font 2 + 2 ? Réponds uniquement avec le chiffre. » Elle rend la règle d'acceptation visible sans introduire de fichiers, d'outils ni d'historique de conversation. Ajoutez des fixtures représentatives de votre application une fois que le contrat de base fonctionne.

Ne considérez pas cette fixture comme un test de raisonnement. Son but est de détecter les régressions d'intégration, comme l'extraction d'un bloc de réflexion en tant que texte destiné à l'utilisateur ou l'acceptation d'une réponse tronquée.

Fixez l'authentification et les paramètres de requête avant de tester

Pour l'API Claude directe, utilisez le point de terminaison Messages, une credential API limitée à l'espace de travail, une version d'API explicite et un corps de requête fixe. Maintenez ces entrées constantes entre les exécutions. La présentation de l'API documente l'authentification Bearer, la sélection de l'espace de travail et les en-têtes de version. Ces paramètres diffèrent de l'authentification IAM des fournisseurs de cloud.

Utilisez une clé API de la Console Claude fournie via votre environnement local de secrets. Un jeton d'accès Apidog authentifie la CLI auprès d'Apidog ; il n'authentifie pas les requêtes adressées à Anthropic. Gardez les deux credentials séparés.

La requête suivante suit la documentation actuelle de Messages, vérifiée le 10 novembre 2026. Enregistrez le JSON sous request.json :

{
  "model": "claude-fable-5-2",
  "max_tokens": 1024,
  "stream": false,
  "thinking": { "type": "adaptive" },
  "messages": [
    {
      "role": "user",
      "content": "What is 2 + 2? Reply with the numeral only."
    }
  ]
}

Envoyez-la ensuite depuis votre terminal ou faites-la exécuter par votre agent de codage :

curl https://api.anthropic.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
  -H 'anthropic-version: 2026-10-21' \
  -H 'Content-Type: application/json' \
  --max-time 600 \
  --dump-header response.headers \
  --output response.json \
  --write-out '%{http_code}\n' \
  --data-binary @request.json

Si votre clé n'est pas limitée à un espace de travail, incluez l'en-tête anthropic-workspace-id documenté pour votre espace de travail cible. N'insérez jamais un credential en clair dans la fixture enregistrée ou un rapport généré.

La référence Create a Message définit model, messages et max_tokens, ainsi que les champs du message renvoyé. Ici, 1 024 est un budget de sortie choisi, pas un minimum documenté ni une garantie que chaque tâche tiendra dedans. Augmentez-le délibérément quand une fixture nécessite plus d'espace.

Il s'agit d'un modèle vérifié par la documentation. Exécutez-le avec votre propre compte API autorisé avant d'enregistrer une base de référence réussie ; aucune réponse Fable en direct ni mesure de latence n'est revendiquée ici.

Ajoutez des assertions de réponse qui résistent à la variation générée

Assertez l'enveloppe, inspectez les types de blocs, extrayez le texte, puis appliquez la règle d'acceptation de la fixture. Une réponse Messages contient un tableau content, donc ne présumez pas que content[0].text contient la réponse. Conservez le message original complet séparément si votre application le renvoie lors de tours de conversation ultérieurs.

Pour la fixture arithmétique, demandez à votre agent d'attacher ce script post-réponse au cas de test Apidog :

pm.test("HTTP success", function () {
  pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("Assistant message contract", function () {
  pm.expect(body.type).to.eql("message");
  pm.expect(body.role).to.eql("assistant");
  pm.expect(body.id).to.be.a("string");
  pm.expect(body.model).to.be.a("string");
  pm.expect(body.content).to.be.an("array");
});

const text = body.content
  .filter(block => block.type === "text")
  .map(block => block.text)
  .join("\n").trim();

pm.test("Arithmetic fixture is complete", function () {
  pm.expect(body.stop_reason).to.eql("end_turn");
  pm.expect(text).to.eql("4");
});

L'égalité exacte a du sens pour ce chiffre délibérément contraint. Pour un résumé, utilisez des critères tels que les faits obligatoires, les affirmations non étayées interdites et les limites de longueur. Une légère reformulation ne devrait pas faire échouer un test de résumé utile.

Enregistrez usage et l'en-tête request-id de la réponse pour le diagnostic. Comparez les identifiants de modèle renvoyés au comportement documenté pour l'identifiant que vous avez choisi ; ne renommez pas silencieusement des réponses de secours en résultats Fable.

Une raison d'arrêt max_tokens signifie que la réponse a atteint sa limite de sortie. Faites échouer cette fixture arithmétique et examinez le budget de jetons. D'autres tâches peuvent légitimement renvoyer des raisons d'arrêt différentes, notamment des demandes d'outils, donc attribuez à chaque cas sa propre règle de complétion.

Testez les cas négatifs de l'API Claude Fable 5.2

Créez un cas distinct pour chaque entrée invalide en modifiant un seul champ à la fois. Vérifiez le statut HTTP et le type d'erreur structuré plutôt que de faire correspondre l'intégralité du message d'erreur lisible. Ne modifiez pas la baseline valide afin qu'une fixture négative ne puisse pas contaminer l'exécution positive suivante.

Le guide officiel des erreurs documente les cas utiles suivants :

Fable 5.2 utilise une réflexion toujours active. Ne copiez pas un ancien tutoriel Claude qui la désactive ou qui configure des budgets d'extended thinking. Le cas de réflexion désactivée est particulièrement utile lors de la mise à niveau d'un code partagé de construction de requêtes.

Pour chaque cas d'erreur, assertez body.type === "error", le body.error.type attendu et un message d'erreur non vide. Conservez un ID de requête lorsqu'il est disponible. Traitez les échecs DNS et les dépassements de délai côté client comme des résultats distincts, car ils peuvent ne jamais produire d'erreur JSON de Claude.

Testez la gestion par votre application des limites de débit et des pannes de service avec des fixtures contrôlées ou un mock. N'inondez pas l'API en production pour provoquer artificiellement un 429. Distinguez les problèmes de capacité réessayables des échecs d'authentification et de validation, et placez un budget de tentatives fini autour de la logique de réessai de votre application.

Laissez votre agent de codage construire les cas de régression Apidog

Fournissez à votre agent le point de terminaison, les fixtures, les assertions et le projet cible. Il peut découvrir le schéma CLI actuel, valider chaque payload, créer les cas de test et les exécuter. Vous examinez les cas générés et le résumé des échecs. Cela maintient le workflow répétable dans l'Apidog CLI.

Installez la CLI et authentifiez-vous avec votre jeton Apidog :

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_APIDOG_TOKEN>

Pour la configuration de l'agent, suivez les guides en direct pour Claude Code ou Codex. Donnez ensuite à votre agent une seule consigne :

In Apidog project <PROJECT_ID>, define POST /v1/messages for the
Claude API. Use model claude-fable-5-2 and version 2026-10-21.
Keep the Anthropic credential in a private runtime variable.
Create the arithmetic success case and four negative cases above.
Read CLI help and input schemas before generating payloads.
Discover valid endpoint and category IDs; validate every payload.
Attach the response assertions, then run each case against
<ENVIRONMENT_ID>. Report failures, request IDs, and token usage.
Do not print credentials or claim unexecuted cases passed.

Les commandes suivantes ont été vérifiées avec la CLI 2.2.12 installée. L'agent a besoin d'un véritable ID de point de terminaison et d'un véritable ID de catégorie ; test-case-create décrit des cas dérivés de points de terminaison, donc créer une requête JSON autonome sans rapport ne suffit pas.

apidog test-case category --project <PROJECT_ID>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <PROJECT_ID> --file case.json
apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json

Faites inspecter à l'agent l'aide et les schémas de la commande du point de terminaison lorsque celui-ci n'existe pas. Utilisez les ID renvoyés, pas des numéros illustratifs copiés d'un autre projet. Validez case.json avant de l'écrire, puis relisez le cas créé pour confirmer que les en-têtes, le corps et les assertions prévus ont bien été enregistrés.

Exécutez les tests de régression de l'API Claude en CI

Exécutez les mêmes cas après tout changement touchant l'authentification, la sérialisation des messages, l'analyse des blocs ou la gestion des réessais. Exportez des rapports lisibles par machine et conservez la version de la fixture en parallèle du changement de votre application. Établissez une baseline réussie avant toute comparaison, puis examinez les échecs un par un au lieu de relancer jusqu'à ce que le build passe par hasard.

Pour un cas déjà créé dans Apidog, une invocation orientée CI est :

apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json,junit \
  --out-dir ./apidog-reports

Répétez pour les autres ID de cas ou laissez votre agent organiser les cas en une suite de tests en utilisant le schéma de suite actuel. Le guide CI/CD d'Apidog couvre l'intégration au pipeline.

Conservez le modèle, la version de l'API, le corps de la requête, le budget de sortie, la révision de la fixture et la version de la CLI dans le rapport d'exécution. Stockez les credentials via le mécanisme de secrets de votre CI. Vérifiez l'absence de données de requête sensibles dans les rapports avant de les partager.

Utilisez un petit ensemble de smoke tests en conditions réelles pour les changements courants et un ensemble comportemental plus large avant les mises en production. Définissez vos propres budgets de dépenses et de durée. Un contrat d'API réussi établit la compatibilité d'intégration ; vos tests d'acceptation propres à l'application établissent si la sortie est utile.

FAQ

Quel ID de modèle dois-je tester ?

Utilisez claude-fable-5-2 pour ce workflow direct sur la plateforme Claude. Vérifiez sa disponibilité dans votre compte avant d'enregistrer une baseline.

Un statut HTTP 200 suffit-il pour valider ?

Non. Vérifiez l'enveloppe du message, le contenu typé, la raison de complétion et les critères d'acceptation de la fixture. Le streaming nécessite des vérifications supplémentaires au niveau des événements, car des échecs peuvent survenir après l'arrivée des en-têtes de réponse.

Puis-je désactiver la réflexion de Fable 5.2 ?

Non. Anthropic documente une réflexion toujours active pour ce modèle. Conservez la réflexion désactivée comme cas négatif qui attend une erreur de validation.

Chaque réponse doit-elle correspondre exactement ?

Utilisez des correspondances exactes pour les fixtures contraintes, comme l'exemple du chiffre. Pour les tâches ouvertes, définissez des critères factuels et structurels qui autorisent une variation de formulation valide.

Mon agent peut-il relancer les tests après un correctif ?

Oui. Fournissez-lui les ID de cas et l'environnement enregistrés, puis faites-lui exécuter les mêmes commandes CLI et résumer les rapports. Commencez par le workflow CLI de Claude Code si vous avez besoin de configurer l'agent.