Blog

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

Apprenez à utiliser les requêtes de base de données dans les tests d'API avec Apidog : alimentez des données, vérifiez des lignes par rapport à MySQL, MongoDB et Redis, et extrayez des valeurs de BDD entre les étapes.

INEZA Felin-Michel

INEZA Felin-Michel

15 July 2026

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

Apidog pour les entreprises

Déploiement sur site

SSO & RBAC

Conforme SOC 2

Découvrir Apidog Enterprise

Un code d'état vert ment. Votre endpoint POST /orders renvoie 201 Created, le corps de la réponse semble parfait et votre test passe. Mais la ligne a-t-elle réellement atterri dans la base de données avec le bon statut ? Le décompte des stocks a-t-il diminué ? Un test qui ne lit que la réponse HTTP vérifie ce que l'API a *dit*, pas ce que le système a *fait*. Pour combler cet écart, vous devez regarder la base de données elle-même.

C'est là que les requêtes de base de données au sein d'un scénario de test prennent tout leur sens. Vous préparez un état connu avant une requête, déclenchez la requête, puis interrogez la table pour confirmer la vérité sur le disque. Apidog intègre cette fonctionnalité via les Connexions de Base de Données et le processeur d'Opération de Base de Données, ce qui vous permet d'exécuter des commandes SQL ou NoSQL comme des étapes dans le même scénario qui pilote vos appels HTTP, sans aucun script externe. Si vous débutez dans la création de scénarios, le guide sur comment écrire un scénario de test avec Apidog couvre les bases au niveau des requêtes sur lesquelles cet article s'appuie. Pour un rappel sur la façon dont les bases de données relationnelles modélisent ces données, l'aperçu côté serveur de MDN est une excellente introduction.

télécharger l'application

Ce que vous apportent les opérations de base de données dans un test

Un test d'API qui ne touche jamais la base de données est une boîte noire. Il fait confiance à la réponse. La plupart du temps, c'est bien, mais les bugs intéressants se trouvent dans l'écart entre ce que l'API renvoie et ce qu'elle persiste : un champ de statut qui ne change jamais, une clé étrangère qui ne pointe nulle part, une suppression douce qui devient une suppression dure.

Les étapes de base de données vous permettent de faire trois choses qu'un test HTTP pur ne peut pas faire :

Apidog divise la fonctionnalité en deux. D'abord, vous créez une connexion réutilisable sous Paramètres > Connexions de Base de Données. Ensuite, vous attachez une étape d'Opération de Base de Données à une requête en tant que Pré-processeur (exécuté avant la requête) ou Post-processeur (exécuté après). Une seule connexion, réutilisée dans chaque scénario du projet.

Une note sur la couverture avant de planifier en fonction. MySQL, SQL Server (2014 et plus récent), PostgreSQL et Oracle fonctionnent sur le plan gratuit. ClickHouse, MongoDB et Redis sont payants. La documentation MongoDB l'indique clairement : la connexion à MongoDB est une fonctionnalité payante. Idem pour Redis. Ainsi, le tutoriel MySQL ci-dessous fonctionne sur le niveau gratuit ; les sections Mongo 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 et cliquez sur + Nouveau en haut à droite. Choisissez votre type de base de données, puis remplissez les champs de connexion :

Si votre base de données se trouve derrière un bastion, développez la section Tunnel SSH et ajoutez les détails de l'hôte de rebond. MySQL expose également un mode SSL avec quatre options : Prefer (la valeur par défaut, qui tente le SSL puis revient en arrière), Require, Verify CA et Verify Full. Choisissez la plus stricte que votre serveur prend en charge. Puis cliquez sur Enregistrer.

Deux pièges de connexion pour vous éviter un après-midi de confusion :

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

Imaginons que vous testiez le flux de création de commande. Vous voulez qu'un client connu existe avant de passer une commande, afin que le test ne dépende pas de ce qui se trouve dans la table.

Ouvrez votre requête, trouvez Pré-processeurs, survolez Ajouter un processeur de base de données et choisissez Opération de base de données. Nommez-le quelque chose comme préparer client, choisissez votre connexion MySQL, puis sous Saisir la commande SQL, écrivez une insertion. Les variables dynamiques utilisent la syntaxe {{variable_name}}, vous pouvez donc récupérer les valeurs directement de votre environnement :

INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';

Maintenant, la requête s'exécute contre un état garanti. Le client existe, est actif et a un ID que vos étapes ultérieures connaissent déjà. La préparation dans un Pré-processeur rend chaque test autonome au lieu de s'appuyer sur les effets secondaires de l'ordre des tests.

Étape 3 : affirmer la vérité par rapport à la base de données avec un Post-processeur

Voici l'essentiel. Votre requête crée une commande. Après son retour, vous interrogez la table orders pour confirmer que la ligne existe avec le bon statut.

Ajoutez la requête qui appelle votre API :

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

{
  "customer_id": {{customer_id}},
  "items": [{ "sku": "APRON-01", "qty": 2 }]
}

Supposons que le corps de la réponse contienne le nouvel ID de commande, que vous capturez dans une variable appelée order_id avec une assertion de réponse normale. Maintenant, ouvrez Post-processeurs sur cette requête. En mode CONCEPTION, vous les trouverez dans l'onglet Exécuter ; en mode DÉBOGAGE, ils se trouvent dans l'onglet Requête. Survolez Ajouter un Post-processeur, sélectionnez Opération de base de données, nommez-le vérifier ligne commande et choisissez votre connexion.

Sous Configurer l'opération, choisissez l'opération et entrez le SQL :

SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};

Les résultats de la requête sont renvoyés sous forme de tableau d'objets, un par ligne. Pour extraire un seul champ, ouvrez Extraire les résultats (Facultatif) et ajoutez une entrée Extraire le résultat vers une variable. Définissez un Nom de variable comme db_order_status et une Expression JSONPath qui isole le champ de la première ligne :

$[0].status

Cliquez sur Envoyer et vérifiez la Console pour voir le résultat brut et la valeur extraite. Maintenant, db_order_status contient ce qui est réellement sur le disque. Ajoutez une assertion qu'il est égal à pending (ou ce que votre API est censée définir), et votre test vérifie enfin la persistance, et non pas seulement l'écho HTTP. Si l'API a renvoyé 201 mais a écrit status = 'draft', c'est cette étape qui le détecte.

Étape 4 : extraire une valeur de base de données et l'utiliser en aval

L'extraction n'est pas seulement pour les assertions. Souvent, la base de données contient une valeur que la réponse ne renvoie jamais, et vous en avez besoin pour la requête suivante.

Imaginez un flux où la création d'une commande génère également une fulfillment_ref interne sur le serveur, écrite dans la ligne mais omise de la réponse de l'API. Votre prochaine requête, GET /api/fulfillments/{ref}, en a besoin. Interrogez-la dans un Post-processeur :

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};

Extrayez-le avec le Nom de variable fulfillment_ref et l'Expression JSONPath $[0].fulfillment_ref. Parce qu'Apidog scope cette variable à l'environnement, votre prochaine requête référence simplement {{fulfillment_ref}} dans son chemin ou son corps et récupère la valeur réelle, générée par le serveur. C'est le même modèle que l'enchaînement des réponses HTTP, couvert dans passer des données entre les étapes de test et orchestration de test API et passage de données, sauf que la source de vérité est une table au lieu d'un corps JSON.

MongoDB et Redis : les variantes NoSQL

Le processeur fonctionne de la même manière pour les bases de données NoSQL, avec une surface de configuration différente. Les deux sont des fonctionnalités payantes, alors planifiez en conséquence. La documentation Apidog contient la référence complète des champs si vous en avez besoin.

MongoDB

Ajoutez une étape d'Opération de Base de Données et sélectionnez MongoDB comme type. Au lieu de SQL brut, vous obtenez un menu déroulant Type d'opération avec Rechercher, Insérer, Mettre à jour, Supprimer et Exécuter la commande de base de données. Pour toute action CRUD, le Nom de la collection est obligatoire. Le champ Condition de requête prend du JSON :

{ "_id": "65486728456e79993a150f1c" }

Apidog convertit automatiquement une chaîne d'ID correspondante en ObjectId, vous n'avez donc pas à l'envelopper vous-même. Lorsque vous avez besoin de types BSON, les helpers ISODate(...), ObjectId(...), NumberDecimal(...) et NumberLong(...) sont pris en charge ; le manuel MongoDB documente comment chacun d'eux correspond à une valeur stockée. La connexion accepte soit une chaîne de connexion complète, soit les composants individuels d'hôte et d'identifiants.

Une note d'honnêteté : le flux MySQL documente l'extraction JSONPath dans une variable, mais les documents MongoDB et Redis ne décrivent pas le même mécanisme d'Extraction du résultat vers une variable. Concentrez-vous donc sur les opérations Mongo pour l'initialisation et la confirmation de l'état, et ne supposez pas que le chemin d'extraction de style SQL fonctionne de manière identique tant que vous ne l'avez pas vérifié dans la Console.

Redis

La connexion Redis demande l'Hôte, le Port, le Mot de passe et l'Index de la base de données. Les opérations visuelles utilisent un menu déroulant Type d'opération prenant en charge GET, SET et DELETE. Pour lire une session mise en cache, choisissez GET et définissez la Clé sur quelque chose comme user:session:123. Pour tout ce que le menu déroulant ne couvre pas, l'onglet Exécuter la commande Redis exécute toute commande valide :

KEYS user:*

C'est ainsi que vous confirmez une entrée de cache que l'API était censée écrire, ou en videz une avant un test pour prouver que l'endpoint la repeuple.

Variations avancées et limites

Quelques éléments à savoir avant de construire une grande suite :

Gérer les identifiants par environnement

Vous ne voulez jamais qu'un test n'affecte accidentellement des données de production. La réponse d'Apidog est une Connexion de Base de Données par environnement. Vous créez une connexion de staging et une connexion locale, chacune avec son propre hôte et mot de passe.

Ensuite, vous changez d'environnement à l'aide du menu déroulant en haut à droite. Apidog achemine automatiquement chaque requête du scénario vers la connexion qui correspond à l'environnement actuellement sélectionné. Sélectionnez staging et votre SELECT s'exécute sur staging ; passez à local et la même étape s'exécute sur la base de données de votre ordinateur portable, sans aucune modification du SQL ou de l'étape. Les identifiants diffèrent par environnement sans aucune reconfiguration manuelle en cours d'exécution.

Parce que ces identifiants sont stockés localement et ne sont pas synchronisés, cela protège également les mots de passe de production du projet cloud partagé. Chaque ingénieur conserve les siens.

Automatiser le flux de travail avec l'Apidog CLI

Une fois que le scénario passe dans l'application, exécutez-le sans interface graphique en CI afin que chaque pull request revérifie la base de données, pas seulement le contrat HTTP. Installez le CLI et authentifiez-vous :

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Ensuite, exécutez le scénario exact que vous avez construit, par son ID, contre un environnement choisi :

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Ici, -t est l'ID du scénario de test, -e est l'ID de l'environnement, et -r est le rapporteur (cli, html ou junit ; séparez-les par des virgules pour plusieurs, comme -r html,cli). Une chose à prévoir : les détails de connexion de la base de données sont locaux, donc le runner a besoin de la configuration exportée pour atteindre votre base de données depuis la CI. Si vous alimentez les lignes du scénario à partir d'un ensemble de données, le test axé sur les données avec l'Apidog CLI montre comment chaque ligne exécute les mêmes assertions de base de données, et la planification des tests API avec Apidog couvre l'exécution de cela à une cadence afin qu'une assertion de base de données défaillante remonte comme n'importe quel autre test.

Foire aux questions

Quelles bases de données sont gratuites et lesquelles sont payantes ? MySQL, SQL Server (2014 et plus récent), PostgreSQL et Oracle sont inclus dans le plan gratuit. ClickHouse, MongoDB et Redis nécessitent un plan payant. La documentation MongoDB et Redis indique toutes deux que leur connectivité est une fonctionnalité payante, alors vérifiez la page des tarifs avant de planifier une suite NoSQL. Téléchargez Apidog pour essayer d'abord les bases de données gratuites.

Puis-je utiliser une valeur de la base de données dans une requête ultérieure ? Oui. Ajoutez un Post-processeur avec une opération de base de données, exécutez un SELECT, puis utilisez Extraire le résultat vers une variable avec un Nom de variable et une Expression JSONPath comme $[0].fulfillment_ref pour isoler le champ de la première ligne. Référencez-le plus tard comme {{variable_name}}. La même idée de chaînage pour les réponses HTTP est couverte dans passer des données entre les étapes de test.

Mes coéquipiers obtiennent-ils automatiquement mes connexions de base de données ? Non. Les identifiants de connexion sont stockés localement sur chaque client et ne sont pas synchronisés avec le cloud, donc chaque membre de l'équipe configure la connexion lui-même. C'est délibéré : cela protège les mots de passe de production du projet partagé.

Ma connexion MySQL 8 échoue constamment. Pourquoi ? MySQL 8 utilise par défaut le plugin d'authentification caching_sha2_password, qui peut bloquer la connexion. Passez l'utilisateur à mysql_native_password avec ALTER USER ... IDENTIFIED WITH mysql_native_password et reconnectez-vous.

Puis-je exécuter des procédures stockées ou une logique de base de données complexe ? Pas via l'interface visuelle. Elle gère les instructions standard SELECT, INSERT, UPDATE et DELETE, mais les opérations complexes comme les procédures stockées ne sont pas prises en charge. Limitez vos étapes de test à des instructions directes.

En résumé

Les requêtes de base de données transforment un test d'API de "la réponse semblait correcte" en "les données sont réellement correctes". Préparez un état connu dans un Pré-processeur, vérifiez la ligne persistante dans un Post-processeur, et extrayez les valeurs générées par le serveur pour les enchaîner dans la requête suivante, le tout dans un seul scénario. Configurez une connexion par environnement et les mêmes étapes s'exécuteront en toute sécurité sur staging ou en local sans modifications.

Essayez-le gratuitement, sans carte de crédit : Téléchargez Apidog, pointez une connexion MySQL vers votre base de données de développement, et ajoutez un Post-processeur qui lit la ligne que votre prochaine requête crée.

Pratiquez le Design-first d'API dans Apidog

Découvrez une manière plus simple de créer et utiliser des API

S'inscrire gratuitementTélécharger