1. API-first
  2. API Testing & Quality Assurance

API Testing & Quality Assurance: Der API-first Ansatz

Contract Testing meistern, Test Automation aufbauen und API-first Qualitätssicherung implementieren. Mit Testing Pyramide, Tools und Best Practices aus 150+ Enterprise-Projekten.

Readiness Check starten

Warum API Testing fundamental anders ist

Ihr Backend-Team meldet, dass die API fertig ist und ready für Integration. Das Frontend-Team integriert – und nach 2 Tagen zeigt sich, dass die API falsche Datentypen liefert, Error Cases nicht behandelt sind, und Performance-Probleme das System unbenutzbar machen. 3 Wochen Bugfixing folgen.

Dieses Szenario ist in Code-first Projekten Standard. Im API-first Ansatz mit proaktivem Testing sieht es anders aus. APIs werden getestet, bevor eine Zeile Implementierungscode geschrieben wird. Contract Tests validieren kontinuierlich Conformance. Integration funktioniert beim ersten Versuch.

API Testing ist nicht "Testing von APIs" – es ist ein fundamentaler Shift. Statt APIs nachträglich zu prüfen, designen Sie Tests parallel zur Spezifikation. Contract Testing wird zur Grundlage. Backend und Frontend entwickeln gegen denselben Contract, automatische Tests verifizieren kontinuierlich Einhaltung.

In diesem Guide lernen Sie die komplette API Testing Pyramide kennen – von Unit über Contract bis End-to-End Tests. Sie erfahren, welche Tools in welchen Szenarien optimal sind, wie DACH-Unternehmen API Testing für Banking und Insurance umsetzen, und welche Fallstricke Sie vermeiden müssen.

Das Ziel: APIs, die beim ersten Deployment funktionieren – nicht nach Wochen Bugfixing.

Die API Testing Pyramide

Die Testing Pyramide gilt auch für APIs, aber mit anderen Schwerpunkten als bei UI-Testing.

Unit Tests für API-Logik

Was wird getestet? Business Logic, Validierung, Daten-Transformationen – isoliert von Netzwerk und Datenbank.

Beispiel aus Banking API:

java 
@Test
public void calculateInterest_validInput_returnsCorrectAmount() {
    Account account = new Account("DE123", 1000.00);
    InterestCalculator calculator = new InterestCalculator();
    double interest = calculator.calculate(account, 0.02, 365);
    assertEquals(20.00, interest, 0.01);
}

Coverage-Ziel: 80%+ für Business Logic

Tools: Java: JUnit 5 & AssertJ | Node.js: Jest & Mocha | .NET: xUnit & NUnit | Python: pytest

Contract Tests - Consumer-driven

Kern-Innovation beim API-first Testing: Contract Tests validieren nicht Implementierung, sondern Contract-Conformance.

Der Unterschied:

  • Integration Test: "Funktioniert der gesamte Flow von A nach Z?"
  • Contract Test: "Hält Backend die API-Spezifikation ein?"

Die richtige Test-Verteilung

Klassische Pyramide (UI-fokussiert): 70/20/10

  • 70% Unit Tests
  • 20% Integration Tests
  • 10% End-to-End Tests

API-first Pyramide: 60/30/10

  • 60% Unit Tests
  • 30% Contract/Integration Tests (Schwerpunkt!)
  • 10% End-to-End Tests

Vollständiger API-first Implementierungsleitfaden

Erfahren Sie, wie Sie API-first in Ihrer Organisation umsetzen: Von der Strategie über Tools, Contract Testing bis zu konkreten Umsetzungsschritten mit ROI-Berechnung.

Contract Testing Workflow

Consumer definiert Erwartung, Provider verifiziert, kontinuierliche Validation im CI/CD

Tool-Ecosystem

Pact, Dredd, Prism, REST Assured, Karate für vollständige Test-Abdeckung

Leitfaden lesen
API-first Implementierung

Contract Testing mit API-first

Was ist Contract Testing?

Contract Testing validiert, dass Provider-API den Contract einhält, den Konsumenten (Frontend, Mobile, Partner) erwarten.

Der Workflow in 3 Schritten:

Schritt 1: Konsument definiert Erwartung

json 
{
  "request": {
    "method": "GET",
    "path": "/accounts/ACC123"
  },
  "response": {
    "status": 200,
    "body": {
      "accountId": "ACC123",
      "balance": 1500.50,
      "currency": "EUR"
    }
  }
}

Schritt 2: Provider verifiziert Contract
Backend-Tests prüfen: "Kann ich diesen Contract erfüllen?"

Schritt 3: Continuous Validation
Bei jedem Deployment werden Contract Tests ausgeführt. Breaking Changes werden sofort erkannt.

Tools: Pact, Spring Cloud Contract, Dredd

Pact ist der führende Contract Testing Framework – polyglott, Open Source.

Consumer-Seite (Frontend):

javascript 
describe('Account API', () => {
  it('retrieves account details', async () => {
    await provider.addInteraction({
      state: 'account ACC123 exists',
      uponReceiving: 'a request for account',
      withRequest: {
        method: 'GET',
        path: '/accounts/ACC123'
      },
      willRespondWith: {
        status: 200,
        body: { accountId: 'ACC123', balance: 1500.50 }
      }
    });
    const account = await accountService.get('ACC123');
    expect(account.balance).toBe(1500.50);
  });
});

Provider-Seite (Backend): Backend verifiziert mit Spring Boot Tests, dass alle Consumer Contracts erfüllt werden.

Alternativen:

  • Spring Cloud Contract: Ideal für Spring-Ökosystem, weniger polyglott
  • Dredd: Einfacher Ansatz, testet direkt gegen OpenAPI Specification

Mock-basiertes Testing

Mock Server direkt aus der OpenAPI-Spezifikation

Prism generiert Mock Server direkt aus OpenAPI Specification – perfekt für Frontend-Entwicklung vor Backend-Fertigstellung.

bash 
npm install -g @stoplight/prism-cli
prism mock openapi.yaml

Prism generiert realistische Responses basierend auf Schemas und Examples. Frontend kann sofort gegen Mock API entwickeln.

WireMock für komplexe Szenarien

WireMock (Java-basiert) bietet erweiterte Funktionen:

  • Stateful Mocks: Session-basierte Szenarien
  • Response Templating: Dynamische Responses basierend auf Request-Daten
  • Delay Simulation: Performance-Tests mit simulierten Latencies
  • Fault Injection: Timeout, 500er Errors für Resilience Testing

Fake vs Mock vs Stub

Unterschiede verstehen:

  • Fake: Vereinfachte Implementierung (z.B. In-Memory Datenbank statt PostgreSQL)
  • Mock: Objekt mit vordefinierten Erwartungen und Verifikation
  • Stub: Liefert vordefinierte Antworten, keine Verifikation

Für API Testing sind Stubs (Prism) und Mocks (WireMock) am relevantesten.

API Test Automation

Tools: Postman/Newman, REST Assured, Karate

Postman/Newman: Collections in UI erstellen, mit Newman in CI/CD ausführen

bash 
newman run api-tests.json --environment production.json

REST Assured (Java): Fluent API für lesbare Tests

java 
given()
  .header("Authorization", "Bearer " + token)
.when()
  .get("/accounts/ACC123")
.then()
  .statusCode(200)
  .body("balance", equalTo(1500.50));

Karate: BDD-Style Tests in Gherkin-Syntax – ideal für Non-Developers

gherkin 
Scenario: Get account details
  Given url 'https://api.bank.de/accounts/ACC123'
  When method get
  Then status 200
  And match response.balance == 1500.50

CI/CD Integration

Best Practice: Tests bei jedem Commit ausführen

  • Unit Tests: Bei jedem Commit (< 2 Minuten)
  • Contract Tests: Bei jedem Merge Request
  • Integration Tests: Nach Deployment zu Test-Environment
  • Performance Tests: Nightly Builds

Test Data Management

Problem: Tests brauchen konsistente Testdaten

Lösungen:

  • Test Fixtures: Vordefinierte Datensätze im Repository
  • Data Builders: Programmatisch Testdaten erzeugen
  • Database Seeding: Test-Datenbank vor jedem Test-Run neu befüllen
  • Synthetic Data Generation: Faker.js, Java Faker für realistische Daten

Performance & Load Testing

Tools: JMeter, Gatling, k6

Apache JMeter: GUI-basiert, etabliert, Enterprise-Standard
Gatling: Scala-basiert, sehr performant, Code-as-Configuration
k6: JavaScript-basiert, Developer-friendly, Cloud-Integration

Wann sind Performance-Tests notwendig?

Immer dann, wenn:

  • APIs öffentlich exponiert werden (Partner, Third-Party Developer)
  • Hohe Lastspitzen erwartet werden (Black Friday, Jahreswechsel)
  • SLAs garantiert werden müssen (99.9% Uptime, < 200ms Response Time)
  • Regulatorische Anforderungen bestehen (BaFin, GDPR)

API Rate Limiting testen

Testen Sie, ob Rate Limits korrekt funktionieren:

javascript 
// k6 Test
export default function () {
  for (let i = 0; i < 120; i++) {
    http.get('https://api.bank.de/accounts');
  }
}

Erwartung: Nach 100 Requests/Minute → HTTP 429 (Too Many Requests)

DACH Compliance: Load Testing vor Production

Banken und Versicherer in DACH müssen Performance nachweisen, bevor APIs in Production gehen. BaFin erwartet Kapazitätsplanung und Load Test Reports.

Security Testing für APIs

OWASP API Security Top 10

Die OWASP API Security Top 10 identifiziert kritischste API-Sicherheitsrisiken:

  1. Broken Object Level Authorization: User A kann Daten von User B abrufen

  2. Broken Authentication: Schwache Token, fehlende MFA

  3. Excessive Data Exposure: API gibt mehr Daten zurück als nötig

  4. Lack of Resources & Rate Limiting: DDoS-Anfälligkeit

  5. Mass Assignment: Request-Body manipuliert unbeabsichtigt Felder

Authentication/Authorization Testing

Testen Sie:

  • Ungültige Tokens werden abgelehnt (HTTP 401)
  • Abgelaufene Tokens werden abgelehnt
  • User kann nur eigene Ressourcen zugreifen (RBAC)
  • Admin-Endpoints sind für Non-Admins blockiert

Input Validation Testing

Fuzzing: Senden Sie ungültige, unerwartete Inputs

  • Null-Values, Empty Strings
  • SQL Injection Payloads
  • XSS Payloads
  • Extremely long Strings (> 10.000 Zeichen)

Erwartung: API lehnt ab mit HTTP 400 (Bad Request), nicht 500 (Server Error)

Monitoring & Observability in Production

Production API Monitoring

Synthetics Tests: Automatisierte Tests gegen Production-APIs

  • Alle 5 Minuten kritische Endpoints aufrufen
  • Response Time, Status Codes, Payload validieren
  • Alerts bei Degradation

Tools: Datadog Synthetics, New Relic Synthetics, Pingdom

Logging und Tracing

Best Practice: Structured Logging

json 
{
  "timestamp": "2025-01-15T10:32:45Z",
  "level": "INFO",
  "requestId": "req-abc-123",
  "userId": "user-456",
  "endpoint": "/accounts/ACC123",
  "responseTime": 45,
  "statusCode": 200
}

Distributed Tracing: Trace Requests über mehrere Services (OpenTelemetry, Jaeger, Zipkin)

Alert-Strategien

Definieren Sie SLIs (Service Level Indicators):

  • Availability: 99.9% Uptime
  • Latency: p95 < 200ms
  • Error Rate: < 0.1%

Alert nur bei SLO-Verletzung: Wenn p95 Latency > 200ms für 5 Minuten → Alert

Häufige Fragen zu API Testing & QA

Die wichtigsten Fragen zu API Testing, Contract Testing und Qualitätssicherung beantwortet

Was ist der Unterschied zwischen Contract Testing und Integration Testing?

Contract Testing validiert, ob eine API ihren definierten Contract (OpenAPI Spec) einhält – unabhängig von der Implementierung. Integration Testing testet das Zusammenspiel mehrerer Komponenten (API + Datenbank + externe Services). Contract Tests sind schneller, fokussierter und weniger fragil als Integration Tests.

Brauche ich Contract Tests wenn ich schon Integration Tests habe?

Ja! Integration Tests sind langsamer, komplexer und testen oft zu viel auf einmal. Contract Tests sind granular, schnell und fangen Breaking Changes früher ab. In API-first Projekten sind Contract Tests die Basis – Integration Tests ergänzen für komplexe Flows.

Welches Tool soll ich für Contract Testing wählen?

Pact ist die beste Wahl für polyglotte Umgebungen (Java, Node.js, Python). Spring Cloud Contract ist optimal für reine Spring Boot Projekte. Dredd ist einfachster Einstieg, testet direkt gegen OpenAPI Spec. Start: Dredd für Quick Wins, Pact für langfristige Strategie.

Wie viele Tests brauche ich für eine API?

Faustregel: 60% Unit Tests (Business Logic), 30% Contract/Integration Tests (Schnittstellen), 10% E2E Tests (kritische Journeys). Eine typische REST API mit 10 Endpoints braucht: 50-100 Unit Tests, 20-30 Contract Tests, 5-10 Integration Tests, 2-5 E2E Tests.

Sollte ich Performance Tests in CI/CD laufen lassen?

Nicht bei jedem Commit. Performance Tests sind langsam (5-30 Minuten) und brauchen realistische Umgebungen. Best Practice: Smoke Performance Tests täglich (Nightly Builds), umfassende Load Tests wöchentlich oder vor Major Releases. Schnelle Response Time Tests (< 1 Sekunde) können in CI/CD.

Wie teste ich Authentication und Authorization?

Erstellen Sie dedizierte Security Test Suites: 1) Ungültige Tokens → HTTP 401. 2) Abgelaufene Tokens → HTTP 401. 3) Fehlende Permissions → HTTP 403. 4) User A zugreift auf Daten von User B → HTTP 403. Tools: REST Assured, Postman mit Pre-Request Scripts für Token-Handling.

Zusammenfassung und nächste Schritte

API Testing im API-first Ansatz ist fundamental anders. Tests werden parallel zur Spezifikation erstellt, nicht nachträglich. Contract Testing wird zum Kern – es validiert kontinuierlich, dass APIs ihren Contract einhalten.

Die wichtigsten Erkenntnisse:

  • API Testing Pyramide: 60% Unit, 30% Contract/Integration, 10% E2E
  • Contract Testing mit Pact, Dredd oder Spring Cloud Contract
  • Mock Server (Prism, WireMock) für Frontend-Entwicklung vor Backend
  • Test Automation mit Postman/Newman, REST Assured, Karate
  • Security Testing: OWASP API Top 10 abdecken
  • Production Monitoring: Synthetics, Logging, Distributed Tracing

Ihre nächsten Schritte

Wenn Sie heute starten:

  1. Schreiben Sie ersten Contract Test mit Dredd gegen OpenAPI Spec

  2. Generieren Sie Mock Server mit Prism für Frontend-Team

  3. Integrieren Sie Contract Tests in CI/CD Pipeline

  4. Machen Sie API-first Readiness Check für individuelle Bewertung

Wenn Sie API Testing skalieren wollen:

  1. Etablieren Sie Pact Broker für Consumer-Driven Contract Testing

  2. Implementieren Sie Synthetic Monitoring für Production APIs

  3. Automatisieren Sie Security Tests (OWASP Top 10)

  4. Bauen Sie Test Data Management Strategie auf

Starten Sie Ihre API Testing Journey heute

Buchen Sie ein kostenloses Strategiegespräch oder machen Sie den 5-Minuten Readiness Check

Strategieberatung buchen