DEV Community

Cover image for Anleitung: Datenbankabfragen in Apidog API-Tests (MySQL, MongoDB, Redis)
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

Anleitung: Datenbankabfragen in Apidog API-Tests (MySQL, MongoDB, Redis)

Ein grüner Statuscode kann täuschen: Ihr POST /orders-Endpunkt liefert 201 Created, der Response-Body sieht korrekt aus und der HTTP-Test besteht. Aber wurde die Bestellung wirklich mit dem richtigen Status gespeichert? Wurde der Lagerbestand reduziert? Ein Test, der nur die HTTP-Antwort prüft, validiert, was die API gesagt hat – nicht, was das System getan hat. Datenbankabfragen im Testszenario schließen genau diese Lücke.

Teste Apidog noch heute

Sie initialisieren vor einer Anfrage einen definierten Zustand, senden den API-Request und lesen anschließend die Datenbank aus. So bestätigen Sie, dass die erwartete Änderung tatsächlich persistiert wurde. Apidog unterstützt Datenbankverbindungen und Datenbankoperationen direkt im Testszenario: SQL- oder NoSQL-Befehle laufen als Schritte neben Ihren HTTP-Aufrufen – ohne externe Skripte. Wenn Sie Szenarien erst einrichten, behandelt der Leitfaden zum Schreiben eines Testszenarios mit Apidog die Grundlagen. Für relationale Datenbanken bietet MDNs server-seitige Übersicht eine Einführung.

Was Datenbankoperationen im Test bringen

Ein reiner HTTP-Test ist eine Black Box: Er vertraut der API-Antwort. Kritische Fehler liegen jedoch oft zwischen Response und Persistenz:

  • Ein Statusfeld wird nicht aktualisiert.
  • Ein Fremdschlüssel verweist auf keinen Datensatz.
  • Ein erwartetes Soft-Delete wird versehentlich als Hard-Delete ausgeführt.
  • Eine Cache- oder Bestandsänderung bleibt aus.

Datenbankschritte ergänzen drei wichtige Fähigkeiten:

  1. Startzustand initialisieren: Jeder Test beginnt mit kontrollierten Daten statt mit Restdaten aus vorherigen Läufen.
  2. Persistenz prüfen: Lesen Sie exakt die Zeile, die Ihre API geschrieben haben soll.
  3. Reale Werte weiterreichen: Extrahieren Sie Datenbankwerte und verwenden Sie sie in nachfolgenden Requests.

In Apidog besteht der Ablauf aus zwei Teilen:

  1. Erstellen Sie unter Einstellungen > Datenbankverbindungen eine wiederverwendbare Verbindung.
  2. Fügen Sie einer Anfrage eine Datenbankoperation als Pre-Processor oder Post-Processor hinzu.

Plan-Hinweis: MySQL, SQL Server ab 2014, PostgreSQL und Oracle funktionieren im kostenlosen Plan. ClickHouse, MongoDB und Redis sind kostenpflichtig. Der folgende MySQL-Ablauf funktioniert daher im kostenlosen Tarif.

Schritt 1: Datenbankverbindung erstellen

Öffnen Sie Einstellungen > Datenbankverbindungen und klicken Sie auf + Neu. Wählen Sie den Datenbanktyp und hinterlegen Sie:

  • Host, etwa db.staging.internal oder 127.0.0.1
  • Port, für MySQL typischerweise 3306
  • Benutzername und Passwort
  • Datenbankname, etwa shop

Liegt Ihre Datenbank hinter einem Bastion Host, konfigurieren Sie den Bereich SSH-Tunnel mit den Daten des Jump Hosts.

Für MySQL stehen außerdem SSL-Modi zur Verfügung:

  • Prefer: versucht SSL und fällt bei Bedarf zurück
  • Require
  • Verify CA
  • Verify Full

Verwenden Sie die strengste Option, die Ihr Server unterstützt, und klicken Sie anschließend auf Speichern.

Häufige Verbindungsprobleme

  • MySQL-8-Authentifizierung: Das Standard-Plugin caching_sha2_password kann Verbindungen verhindern. Bei Authentifizierungsfehlern kann ein Benutzer auf mysql_native_password umgestellt werden: 
  ALTER USER 'tester'@'%'
  IDENTIFIED WITH mysql_native_password BY '...';
Enter fullscreen mode Exit fullscreen mode

Details dazu finden Sie im MySQL-Referenzhandbuch.

  • Verbindungsdaten sind lokal: Datenbankverbindungen werden auf dem jeweiligen Rechner gespeichert und nicht mit der Cloud synchronisiert. Jedes Teammitglied konfiguriert seine Verbindung selbst. Der Workflow ist im Beitrag zum Teilen von Datenbankverbindungseinstellungen beschrieben.

Schritt 2: Testdaten mit einem Pre-Processor initialisieren

Angenommen, Sie testen einen Bestellablauf. Vor dem Request soll ein definierter, aktiver Kunde existieren.

Öffnen Sie die Anfrage und fügen Sie unter Pre-Processors eine Datenbankoperation hinzu:

  1. Bewegen Sie den Mauszeiger über Datenbankprozessor hinzufügen.
  2. Wählen Sie Datenbankoperation.
  3. Benennen Sie den Schritt, etwa seed customer.
  4. Wählen Sie Ihre MySQL-Verbindung.
  5. Fügen Sie den SQL-Befehl ein. 
INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';
Enter fullscreen mode Exit fullscreen mode

Die Syntax {{variable_name}} verwendet Werte aus Ihrer Umgebung. Der Test startet damit immer mit demselben fachlichen Zustand:

  • Der Kunde existiert.
  • Der Kunde ist aktiv.
  • Die Kunden-ID ist für alle Folgeschritte bekannt.

Damit wird der Test unabhängig von Ausführungsreihenfolge und Altlasten in der Datenbank.

Schritt 3: Persistierte Daten mit einem Post-Processor prüfen

Jetzt folgt der zentrale Schritt: Ihre API legt eine Bestellung an, und der Test liest danach die Tabelle orders, um den gespeicherten Zustand zu validieren.

Beispielrequest:

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

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

Nehmen wir an, Sie extrahieren die Bestell-ID aus dem Response-Body in die Variable order_id.

Fügen Sie anschließend unter Post-Processors eine Datenbankoperation hinzu:

  • Im DESIGN-Modus finden Sie Post-Processors im Tab Ausführen.
  • Im DEBUG-Modus finden Sie sie im Tab Anfrage.
  • Benennen Sie den Schritt beispielsweise verify order row.

Verwenden Sie diese Abfrage:

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

Das Ergebnis ist ein Array von Objekten, also eine Struktur wie:

[
  {
    "id": 42,
    "status": "pending",
    "total_cents": 4990
  }
]
Enter fullscreen mode Exit fullscreen mode

Um den Status weiterzuverwenden:

  1. Öffnen Sie Ergebnisse extrahieren (Optional).
  2. Fügen Sie Ergebnis in Variable extrahieren hinzu.
  3. Verwenden Sie als Variablenname db_order_status.
  4. Setzen Sie diesen JSONPath-Ausdruck: 
$[0].status
Enter fullscreen mode Exit fullscreen mode

Prüfen Sie nach dem Ausführen die Konsole. Sie sehen dort das Roh-Ergebnis sowie den extrahierten Wert. Anschließend fügen Sie eine Assertion hinzu:

db_order_status == pending
Enter fullscreen mode Exit fullscreen mode

Damit erkennt Ihr Test auch Fälle, in denen die API zwar 201 Created zurückgibt, aber beispielsweise status = 'draft' in die Datenbank schreibt.

Schritt 4: Datenbankwerte in nachfolgenden Requests verwenden

Datenbankabfragen eignen sich nicht nur für Assertions. Sie können auch Werte lesen, die Ihre API nicht im Response zurückgibt.

Beispiel: Beim Erstellen einer Bestellung generiert der Server eine interne fulfillment_ref. Sie wird in orders gespeichert, fehlt aber in der API-Antwort. Der nächste Request benötigt diesen Wert:

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

Extrahieren Sie das Ergebnis als:

  • Variablenname: fulfillment_ref
  • JSONPath: $[0].fulfillment_ref

Verwenden Sie die Variable anschließend direkt im nächsten Request:

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

Das ist dasselbe Grundprinzip wie beim Verketten von HTTP-Responses, aber die Datenquelle ist hier die persistierte Datenbank. Weitere Beispiele finden Sie unter Daten zwischen Testschritten übergeben und API-Testorchestration und Datenübergabe.

MongoDB und Redis: NoSQL-Varianten

MongoDB und Redis verwenden denselben grundlegenden Ablauf: Verbindung erstellen, Datenbankoperation als Pre- oder Post-Processor ausführen, Ergebnis prüfen.

Beide Integrationen sind kostenpflichtig. Die vollständige Feldreferenz finden Sie in der Apidog-Dokumentation.

MongoDB

Wählen Sie in der Datenbankoperation MongoDB. Statt SQL verwenden Sie den Operationstyp:

  • Find
  • Insert
  • Update
  • Delete
  • Datenbankbefehl ausführen

Für CRUD-Operationen ist der Sammlungsname erforderlich. Die Abfragebedingung erwartet JSON:

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

Eine passende ID-Zeichenfolge wird automatisch in eine ObjectId umgewandelt. Für BSON-Typen werden unter anderem diese Hilfsfunktionen unterstützt:

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

Details zu den Typen beschreibt das MongoDB-Handbuch.

Der MySQL-Ablauf dokumentiert die JSONPath-Extraktion in Variablen. Bei MongoDB und Redis wird derselbe Mechanismus nicht explizit beschrieben. Verifizieren Sie die Ergebnisse daher zunächst in der Konsole, bevor Sie sich auf identisches Extraktionsverhalten verlassen.

Redis

Für eine Redis-Verbindung konfigurieren Sie:

  • Host
  • Port
  • Passwort
  • Datenbankindex

Die visuelle Oberfläche unterstützt die Operationen:

  • GET
  • SET
  • DELETE

Um eine Cache-Session zu prüfen, wählen Sie GET und verwenden etwa diesen Schlüssel:

user:session:123
Enter fullscreen mode Exit fullscreen mode

Für weitere Redis-Kommandos verwenden Sie den Tab Redis-Befehl ausführen:

KEYS user:*
Enter fullscreen mode Exit fullscreen mode

Damit können Sie beispielsweise einen Cache-Eintrag vor einem Test löschen und danach prüfen, ob der API-Endpunkt ihn neu angelegt hat.

Fortgeschrittene Variationen und Grenzen

Beachten Sie diese Punkte beim Aufbau größerer Test-Suites:

  • Schleifen: In einem ForEach-Schritt referenzieren Sie das aktuelle Element mit: 
  {{$.StepID.element.field}}
Enter fullscreen mode Exit fullscreen mode

Ersetzen Sie StepID durch die tatsächliche Nummer des Schleifenschritts.

  • Bedingte Pfade: Extrahieren Sie einen Datenbankstatus und steuern Sie darauf basierend den weiteren Ablauf. Die Kombination mit bedingter Logik in API-Testszenarien ermöglicht unterschiedliche Pfade für paid und pending.

  • Umgebungen: Definieren Sie eine Verbindung pro Umgebung. So führt derselbe Schritt SQL gegen lokale Datenbanken oder Staging aus.

  • Gespeicherte Prozeduren: Die visuelle Oberfläche unterstützt keine komplexen Operationen wie Stored Procedures. Beschränken Sie Datenbankschritte auf direkte Anweisungen wie SELECT, INSERT, UPDATE und DELETE.

  • Oracle: Vor dem Verbindungsaufbau muss ein Oracle Client lokal installiert sein.

Anmeldeinformationen pro Umgebung verwalten

Ein Test darf niemals versehentlich auf Produktionsdaten laufen. Legen Sie deshalb Datenbankverbindungen pro Umgebung an, zum Beispiel:

  • local
  • staging

Jede Verbindung erhält ihren eigenen Host, Port, Benutzer und ihr eigenes Passwort. Wechseln Sie die Umgebung im Dropdown oben rechts:

  • In staging läuft Ihr SELECT gegen die Staging-Datenbank.
  • In local läuft derselbe Schritt gegen Ihre lokale Datenbank.

Sie müssen weder SQL noch Testschritte ändern. Da Anmeldeinformationen lokal gespeichert werden, bleiben sensible Produktionspasswörter außerhalb des geteilten Cloud-Projekts.

Tests mit der Apidog CLI automatisieren

Wenn Ihr Szenario lokal funktioniert, führen Sie es in CI aus. So prüft jeder Pull Request nicht nur den HTTP-Vertrag, sondern auch die Datenbankpersistenz.

Installieren Sie die CLI und authentifizieren Sie sich:

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

Starten Sie dann ein Testszenario für eine bestimmte Umgebung:

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

Parameter:

  • -t: ID des Testszenarios
  • -e: Umgebungs-ID
  • -r: Reporter, etwa cli, html oder junit

Mehrere Reporter können Sie per Komma angeben:

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

Beachten Sie: Datenbankverbindungen sind lokal. Ihr CI-Runner benötigt daher die exportierte Konfiguration, um die Datenbank erreichen zu können. Für parameterisierte Runs lesen Sie datengetriebenes Testen mit der Apidog CLI. Regelmäßige Ausführungen behandelt API-Tests mit Apidog planen.

Häufig gestellte Fragen

Welche Datenbanken sind kostenlos, welche kostenpflichtig?

MySQL, SQL Server ab 2014, PostgreSQL und Oracle sind im kostenlosen Plan enthalten. ClickHouse, MongoDB und Redis benötigen einen kostenpflichtigen Plan. Sie können die kostenlosen Datenbanken mit Apidog herunterladen ausprobieren.

Kann ich einen Datenbankwert in einer späteren Anfrage verwenden?

Ja. Führen Sie in einem Post-Processor ein SELECT aus und extrahieren Sie das Feld mit Ergebnis in Variable extrahieren und einem JSONPath wie:

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

Referenzieren Sie die Variable später als:

{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

Das gleiche Verkettungsmuster für HTTP-Responses beschreibt Daten zwischen Testschritten übergeben.

Erhalten Teammitglieder meine Datenbankverbindungen automatisch?

Nein. Verbindungsdetails werden lokal gespeichert und nicht mit der Cloud synchronisiert. Jedes Teammitglied richtet die Verbindung selbst ein. Das schützt insbesondere Produktionsanmeldeinformationen.

Warum schlägt meine MySQL-8-Verbindung fehl?

MySQL 8 verwendet standardmäßig caching_sha2_password. Dieses Plugin kann die Verbindung blockieren. Stellen Sie den Testbenutzer bei Bedarf auf mysql_native_password um:

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

Kann ich Stored Procedures ausführen?

Nicht über die visuelle Oberfläche. Verwenden Sie direkte SQL-Anweisungen wie SELECT, INSERT, UPDATE und DELETE.

Zusammenfassung

Datenbankabfragen machen aus einem API-Test eine echte Persistenzprüfung:

  1. Initialisieren Sie Testdaten in einem Pre-Processor.
  2. Rufen Sie Ihre API auf.
  3. Prüfen Sie die gespeicherte Zeile in einem Post-Processor.
  4. Extrahieren Sie serverseitig erzeugte Werte für Folgerequests.
  5. Trennen Sie lokale, Staging- und Produktionsverbindungen konsequent nach Umgebung.

Starten Sie mit einer MySQL-Verbindung zu Ihrer Entwicklungsdatenbank und prüfen Sie nach dem nächsten POST die gerade erzeugte Zeile direkt per SELECT. Apidog herunterladen.

Top comments (0)