DEV Community

Cover image for Comment utiliser les requêtes de base de données dans les tests d'API avec Apidog (MySQL, MongoDB, Redis)
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Comment utiliser les requêtes de base de données dans les tests d'API avec Apidog (MySQL, MongoDB, Redis)

Un code d’état vert peut mentir. Votre endpoint POST /orders renvoie 201 Created, le corps semble correct et le test passe. Mais la ligne a-t-elle été enregistrée avec le bon statut ? Le stock a-t-il réellement diminué ? Un test HTTP seul valide ce que l’API déclare, pas ce que le système persiste. Pour vérifier le résultat réel, interrogez la base de données.

Essayez Apidog dès aujourd’hui

Les opérations de base de données dans un scénario permettent de préparer un état connu, d’appeler l’API, puis de vérifier les données persistées. Apidog propose cela via les Connexions de Base de Données et le processeur Opération de Base de Données : vous exécutez des commandes SQL ou NoSQL dans le même scénario que vos requêtes HTTP, sans script externe.

Si vous découvrez les scénarios, consultez le guide sur la création d’un scénario de test avec Apidog. Pour revoir les fondamentaux relationnels, l’aperçu côté serveur de MDN est un bon point de départ.

Pourquoi ajouter des opérations de base de données aux tests API ?

Un test HTTP classique est une boîte noire : il fait confiance à la réponse. Or, les bugs les plus coûteux apparaissent souvent entre la réponse envoyée et les données écrites :

  • un statut qui ne change jamais ;
  • une clé étrangère invalide ;
  • une suppression douce transformée en suppression définitive ;
  • un cache ou un compteur de stock non mis à jour.

Les étapes de base de données répondent à trois besoins concrets :

  1. Préparer un état initial déterministe.
  2. Vérifier la ligne réellement écrite par l’API.
  3. Extraire une valeur générée côté serveur pour la réutiliser dans les requêtes suivantes.

Dans Apidog, le flux est simple :

  1. Créez une connexion dans Paramètres > Connexions de Base de Données.
  2. Ajoutez une Opération de Base de Données à une requête :
    • comme Pré-processeur pour préparer les données ;
    • comme Post-processeur pour contrôler le résultat.

MySQL, SQL Server 2014+, PostgreSQL et Oracle sont disponibles avec le plan gratuit. ClickHouse, MongoDB et Redis nécessitent un plan payant.

Étape 1 : créer une connexion de base de données

Ouvrez Paramètres > Connexions de Base de Données, puis cliquez sur + Nouveau.

Renseignez les paramètres de connexion :

  • Hôte : par exemple db.staging.internal ou 127.0.0.1
  • Port : 3306 pour MySQL
  • Nom d’utilisateur
  • Mot de passe
  • Nom de la base : par exemple shop

Configuration d’une connexion de base de données dans Apidog

Si votre base est accessible via un bastion, configurez un Tunnel SSH.

Pour MySQL, choisissez le mode SSL le plus strict supporté par votre serveur :

  • Prefer : essaie SSL puis revient à une connexion non chiffrée ;
  • Require ;
  • Verify CA ;
  • Verify Full.

Enregistrez ensuite la connexion.

Dépanner une connexion MySQL 8

MySQL 8 utilise souvent le plugin caching_sha2_password. Si l’authentification échoue, basculez l’utilisateur vers mysql_native_password :

ALTER USER 'tester'@'%'
IDENTIFIED WITH mysql_native_password BY '...';
Enter fullscreen mode Exit fullscreen mode

Consultez le manuel de référence MySQL pour les différences entre plugins d’authentification.

Les connexions sont stockées localement et ne sont pas synchronisées avec le cloud. Chaque membre de l’équipe doit configurer ses propres identifiants. Consultez le guide sur le partage des paramètres de connexion pour organiser ce workflow.

Étape 2 : préparer les données avec un Pré-processeur

Supposons que vous testiez la création d’une commande. Avant l’appel API, assurez-vous qu’un client actif existe.

Dans votre requête :

  1. Ouvrez Pré-processeurs.
  2. Sélectionnez Ajouter un processeur de base de données > Opération de base de données.
  3. Nommez l’étape, par exemple préparer client.
  4. Sélectionnez votre connexion MySQL.
  5. Ajoutez l’instruction SQL suivante : 
INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';
Enter fullscreen mode Exit fullscreen mode

Les variables Apidog utilisent la syntaxe {{variable_name}}.

Cette préparation rend le test autonome : il ne dépend ni de données résiduelles ni de l’ordre d’exécution des tests.

Étape 3 : vérifier les données avec un Post-processeur

Ajoutez maintenant la requête qui crée une commande :

POST /api/orders
Content-Type: application/json

{
  "customer_id": {{customer_id}},
  "items": [{ "sku": "APRON-01", "qty": 2 }]
}
Enter fullscreen mode Exit fullscreen mode

Capturez l’ID de commande retourné par l’API dans une variable order_id.

Ajoutez ensuite un Post-processeur :

  1. Ouvrez Post-processeurs.
    • En mode CONCEPTION, utilisez l’onglet Exécuter.
    • En mode DÉBOGAGE, utilisez l’onglet Requête.
  2. Sélectionnez Ajouter un Post-processeur > Opération de base de données.
  3. Nommez l’étape vérifier ligne commande.
  4. Exécutez cette requête : 
SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

Le résultat est renvoyé sous la forme d’un tableau d’objets. Pour isoler le statut de la première ligne :

  • Nom de variable : db_order_status
  • Expression JSONPath : 
$[0].status
Enter fullscreen mode Exit fullscreen mode

Exécutez la requête et consultez la Console. Ajoutez ensuite une assertion sur db_order_status, par exemple avec la valeur attendue pending.

Votre scénario vérifie désormais la persistance réelle. Si l’API répond 201 mais écrit status = 'draft', le test échoue.

Étape 4 : réutiliser une valeur extraite de la base

L’extraction ne sert pas uniquement aux assertions. Elle permet aussi d’enchaîner des requêtes avec des valeurs absentes de la réponse API.

Exemple : la création d’une commande génère une référence interne fulfillment_ref, stockée en base mais non renvoyée par l’endpoint.

Ajoutez ce Post-processeur :

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

Configurez ensuite :

  • Nom de variable : fulfillment_ref
  • Expression JSONPath : 
$[0].fulfillment_ref
Enter fullscreen mode Exit fullscreen mode

Votre requête suivante peut alors utiliser la valeur réelle :

GET /api/fulfillments/{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

Le principe est identique au chaînage de réponses HTTP, expliqué dans passer des données entre les étapes de test et l’orchestration de tests API, mais la source de vérité est ici une table de base de données.

MongoDB et Redis : variantes NoSQL

MongoDB et Redis sont des fonctionnalités payantes. Consultez la documentation Apidog pour les champs et options disponibles.

MongoDB

Sélectionnez MongoDB comme type de connexion et ajoutez une étape Opération de Base de Données.

Les opérations disponibles incluent :

  • Rechercher ;
  • Insérer ;
  • Mettre à jour ;
  • Supprimer ;
  • Exécuter la commande de base de données.

Pour les opérations CRUD, renseignez le Nom de la collection. La condition de recherche utilise du JSON :

{ "_id": "65486728456e79993a150f1c" }
Enter fullscreen mode Exit fullscreen mode

Apidog convertit automatiquement une chaîne d’ID compatible en ObjectId.

Les helpers BSON suivants sont pris en charge :

ISODate(...)
ObjectId(...)
NumberDecimal(...)
NumberLong(...)
Enter fullscreen mode Exit fullscreen mode

Le manuel MongoDB documente ces types et leur stockage.

Le flux SQL documente l’extraction JSONPath vers une variable. Les documents MongoDB et Redis ne décrivent pas explicitement le même mécanisme. Vérifiez le résultat dans la Console avant de dépendre de cette extraction dans un scénario NoSQL.

Redis

Une connexion Redis nécessite :

  • Hôte
  • Port
  • Mot de passe
  • Index de la base de données

Les opérations visuelles incluent GET, SET et DELETE.

Pour lire une session :

GET user:session:123
Enter fullscreen mode Exit fullscreen mode

Pour les commandes non couvertes par le menu, utilisez l’onglet Exécuter la commande Redis :

KEYS user:*
Enter fullscreen mode Exit fullscreen mode

Vous pouvez ainsi vérifier qu’un endpoint a alimenté le cache ou supprimer une clé avant un test pour confirmer que l’API la recrée.

Variations avancées et limites

Quelques points à connaître avant de généraliser cette approche :

  • Boucles : dans une étape ForEach, référencez l’élément courant avec {{$.StepID.element.field}}, où StepID est l’identifiant réel de l’étape de boucle.
  • Logique conditionnelle : extrayez un statut depuis la base, puis routez le scénario selon sa valeur. Consultez la logique conditionnelle dans les scénarios de test API.
  • Routage par environnement : associez une connexion distincte à chaque environnement.
  • Procédures stockées : l’interface visuelle est adaptée aux requêtes directes SELECT, INSERT, UPDATE et DELETE, pas aux opérations complexes comme les procédures stockées.
  • Oracle : un client Oracle doit être installé localement avant la connexion.

Gérer les connexions par environnement

Ne laissez jamais un test pointer accidentellement vers la production.

Créez une connexion par environnement, par exemple :

  • local
  • staging

Chaque connexion possède son propre hôte, nom d’utilisateur et mot de passe. Ensuite, sélectionnez l’environnement depuis le menu en haut à droite.

Le même SQL reste inchangé :

SELECT id, status
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

Mais il s’exécute contre la base correspondant à l’environnement actif :

  • environnement staging : base de staging ;
  • environnement local : base locale.

Comme les identifiants restent stockés localement, ils ne sont pas exposés dans le projet cloud partagé.

Exécuter les scénarios en CI avec Apidog CLI

Une fois le scénario validé dans l’interface, exécutez-le en CI pour vérifier à chaque pull request le contrat HTTP et la persistance.

Installez le CLI et authentifiez-vous :

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Enter fullscreen mode Exit fullscreen mode

Lancez ensuite le scénario avec l’environnement ciblé :

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Options principales :

  • -t : ID du scénario de test ;
  • -e : ID de l’environnement ;
  • -r : rapporteur, par exemple cli, html ou junit.

Vous pouvez utiliser plusieurs rapporteurs :

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t <scenario_id> \
  -e <env_id> \
  -r html,cli
Enter fullscreen mode Exit fullscreen mode

Les connexions de base étant locales, votre runner CI doit disposer de la configuration nécessaire pour atteindre la base concernée.

Pour exécuter le même scénario sur plusieurs jeux de données, consultez le guide sur les tests axés sur les données avec Apidog CLI. Pour une exécution planifiée, consultez la planification des tests API avec Apidog.

Foire aux questions

Quelles bases sont incluses dans le plan gratuit ?

MySQL, SQL Server 2014+, PostgreSQL et Oracle sont inclus. ClickHouse, MongoDB et Redis nécessitent un plan payant. Vous pouvez télécharger Apidog pour tester les connexions aux bases prises en charge gratuitement.

Puis-je utiliser une valeur de base dans une requête suivante ?

Oui. Exécutez un SELECT dans un Post-processeur, puis utilisez Extraire le résultat vers une variable avec un JSONPath comme :

$[0].fulfillment_ref
Enter fullscreen mode Exit fullscreen mode

Réutilisez ensuite la valeur avec :

{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

Le chaînage de données entre étapes est également détaillé dans passer des données entre les étapes de test.

Les connexions sont-elles partagées automatiquement avec mon équipe ?

Non. Les identifiants sont stockés localement sur chaque machine et ne sont pas synchronisés avec le cloud. Chaque membre configure sa propre connexion.

Pourquoi ma connexion MySQL 8 échoue-t-elle ?

Le plugin caching_sha2_password peut empêcher l’authentification. Utilisez mysql_native_password pour l’utilisateur de test :

ALTER USER 'tester'@'%'
IDENTIFIED WITH mysql_native_password BY '...';
Enter fullscreen mode Exit fullscreen mode

Puis-je appeler une procédure stockée ?

Non, pas via l’interface visuelle. Limitez les étapes aux instructions directes telles que SELECT, INSERT, UPDATE et DELETE.

En résumé

Les opérations de base de données font passer vos tests API de :

« La réponse semble correcte »

à :

« Les données persistées sont correctes »

Appliquez ce workflow :

  1. Préparez les données dans un Pré-processeur.
  2. Appelez l’endpoint.
  3. Vérifiez la ligne écrite dans un Post-processeur.
  4. Extrayez les valeurs générées côté serveur pour les requêtes suivantes.
  5. Associez une connexion à chaque environnement pour éviter tout accès involontaire à la production.

Pour démarrer, téléchargez Apidog, configurez une connexion MySQL vers votre environnement de développement et ajoutez un Post-processeur SELECT après votre prochain endpoint de création.

Top comments (0)