Du PRD à la Boucle de Tests : Un Flux de Travail d'Automatisation Complet avec Apidog CLI

Ceci est une série en 10 parties expliquant comment Apidog a développé Apidog CLI, un outil en ligne de commande pour les tests d'API et la gestion du cycle de vie des API. Lisez dans l'ordre ou accédez à n'importe quel article qui vous intéresse :

Découvrez un exemple concret : une équipe dispose d'un PRD (Document de Spécification des Exigences Produit) et d'une base de code pour le remboursement de commandes. Voyez comment un Agent utilise Apidog CLI + SKILL pour générer des spécifications OpenAPI, créer des tests, valider et vérifier—de bout en bout.

Le Scénario

Rendons tout cela concret avec un véritable flux de travail.

Contexte :

Une équipe vient de terminer la rédaction d'un PRD "Remboursement de commande". La base de code dispose déjà des routes et contrôleurs correspondants.

Demande de l'utilisateur à l'Agent :

"Générez des tests API pour la fonctionnalité de remboursement basés sur le PRD et la base de code, puis exécutez la vérification."

Le Problème de l'Ancienne Approche

Avec les outils MCP, l'Agent est confronté à une série de dilemmes :

L'Agent passe un temps considérable à décider du chemin à suivre—plutôt qu'à exécuter la tâche.

Le Chemin CLI + SKILL

CLI + SKILL satisfait les véritables flux de R&D avec une séquence claire :

Générer OpenAPI à partir du PRD et de la base de code
        ↓
Importer dans Apidog
        ↓
Ajouter des cas de test pour un seul point d'accès
        ↓
Valider avant d'écrire
        ↓
Générer un scénario de test pour le flux métier
        ↓
Valider avant d'écrire
        ↓
Exécuter des tests automatisés

Passons en revue chaque étape.

Étape 1 : Générer et Importer OpenAPI

L'Agent lit le PRD et la base de code, puis génère la spécification OpenAPI.

Extrait du PRD :

Order Refund API

POST /api/orders/{orderId}/refund
- Request body: { "reason": string, "amount": number }
- Response: { "refundId": string, "status": string, "processedAt": datetime }

GET /api/orders/{orderId}/refund/{refundId}
- Response: { "refundId": string, "status": string, "amount": number }

L'Agent génère OpenAPI :

{
  "openapi": "3.0.0",
  "paths": {
    "/api/orders/{orderId}/refund": {
      "post": {
        "summary": "Create refund request",
        "parameters": [...],
        "requestBody": {...},
        "responses": {...}
      }
    },
    "/api/orders/{orderId}/refund/{refundId}": {
      "get": {
        "summary": "Get refund status",
        ...
      }
    }
  }
}

Importer dans Apidog :

apidog import --project <projectId> --format openapi --file ./openapi.json

Sortie CLI :

{
  "success": true,
  "data": {
    "importedEndpoints": ["POST /refund", "GET /refund/{refundId}"],
    "endpointIds": ["ep-001", "ep-002"]
  },
  "agentHints": {
    "summary": "OpenAPI importé avec succès. 2 points d'accès créés.",
    "nextSteps": [
      "Liste les points d'accès importés pour confirmer la structure.",
      "Ajoutez des cas de test pour chaque point d'accès.",
      "Créez un scénario de test pour le flux de remboursement complet."
    ]
  }
}

Étape 2 : Cas de Test pour Point d'Accès Unique

L'Agent se concentre d'abord sur le "point d'accès de remboursement".

L'Agent lit le point d'accès :

apidog endpoint get ep-001 --project <projectId>

Le CLI renvoie la structure du point d'accès :

{
  "id": "ep-001",
  "method": "POST",
  "path": "/api/orders/{orderId}/refund",
  "requestBody": {
    "schema": {
      "type": "object",
      "properties": {
        "reason": { "type": "string" },
        "amount": { "type": "number" }
      },
      "required": ["reason", "amount"]
    }
  },
  "responses": {
    "200": {...}
  }
}

L'Agent génère un cas de test :

{
  "name": "Create refund - success",
  "endpointId": "ep-001",
  "request": {
    "path": "/api/orders/order-123/refund",
    "body": {
      "reason": "Customer request",
      "amount": 99.99
    }
  },
  "assertions": [
    {
      "subject": "responseJson.status",
      "comparator": "equal",
      "target": "processed"
    }
  ]
}

Valider avant d'écrire :

apidog cli-schema validate test-case-create --file ./test-case-create.json

Résultat de la validation CLI :

{
  "success": true,
  "agentHints": {
    "summary": "La structure du cas de test est valide.",
    "nextSteps": [
      "Créez le cas de test dans Apidog.",
      "Relisez le cas de test créé pour confirmer.",
      "Ajoutez d'autres assertions si nécessaire."
    ]
  }
}

Créer un cas de test :

apidog test-case create --project <projectId> --file ./test-case-create.json

Sortie CLI :

{
  "success": true,
  "data": {
    "id": "tc-001",
    "name": "Create refund - success"
  },
  "agentHints": {
    "summary": "Cas de test créé avec succès.",
    "nextSteps": [
      "Relisez le cas de test tc-001 pour confirmer les assertions.",
      "Créez un cas de test pour GET /refund/{refundId}.",
      "Construisez un scénario de test pour le flux de remboursement complet."
    ]
  }
}

Étape 3 : Scénario de Test pour le Flux Complet

Basé sur le PRD, le flux métier complet est le suivant :

Créer la commande → Payer → Rembourser → Interroger le statut du remboursement

L'Agent génère le scénario :

{
  "name": "Order Refund Complete Flow",
  "steps": [
    { "type": "case", "caseId": "tc-create-order" },
    { "type": "case", "caseId": "tc-pay" },
    { "type": "case", "caseId": "tc-001" },
    { "type": "case", "caseId": "tc-get-refund" }
  ]
}

Valider avant d'écrire :

apidog cli-schema validate test-scenario-update --file ./scenario-update.json

Créer un scénario :

apidog test-scenario create --project <projectId> --file ./scenario-update.json

Étape 4 : Exécuter la Vérification

Une fois les cas de test et les scénarios prêts :

apidog run --project <projectId> \
  --test-scenario scenario-001 \
  --environment env-production \
  -r "cli,html,junit" \
  --out-dir ./apidog-reports

Sortie CLI :

{
  "success": true,
  "stats": {
    "total": 4,
    "passed": 4,
    "failed": 0
  },
  "reportFiles": {
    "cli": "./apidog-reports/cli-report.txt",
    "html": "./apidog-reports/report.html",
    "junit": "./apidog-reports/junit.xml"
  },
  "agentHints": {
    "summary": "Tous les tests ont réussi. 4 étapes exécutées avec succès.",
    "nextSteps": [
      "Examinez le rapport HTML pour des résultats détaillés.",
      "Si des échecs se sont produits, déboguez en utilisant les détails d'erreur du CLI.",
      "Intégrez ce test dans le pipeline CI."
    ]
  }
}

La Chaîne Complète

Tous les éléments sont maintenant connectés :

Tout est vérifiable et traçable.

agentHints Tout au Long du Flux

Remarquez comment agentHints guide chaque transition :

L'Agent n'a jamais à deviner la prochaine étape.

Comparaison : MCP vs. CLI + SKILL pour cette Tâche

Quelle Est la Suite

Cet exemple pratique montre comment CLI + SKILL fonctionne dans un flux de travail réel.

Mais il y a une fondation sous tout cela : la compatibilité CI/CD.

Dans la partie 8, Pourquoi la compatibilité CI/CD est non négociable pour les outils d'agent, nous explorerons pourquoi apidog run sert à la fois les pipelines CI et les Agents IA—et pourquoi cette double finalité est importante pour la conception d'outils durables.

Points Clés à Retenir

• Flux de travail complet : PRD → OpenAPI → Importation → Cas de Test → Scénario → Vérification
• Chaque étape comprend une commande CLI + validation + agentHints
• L'importation d'étapes + la relecture est plus sûre que l'écriture manuelle de scénarios
• --with-case-detail fournit une structure réelle pour les mises à jour
• agentHints guide chaque transition
• Tout est vérifiable et traçable

Téléchargez Apidog pour concevoir, simuler, tester et documenter des API dans un seul espace de travail. Apprenez-en davantage sur Apidog CLI pour les tests d'API en ligne de commande, l'automatisation CI et les flux de travail des Agents IA.

bouton