API-Test-Designer

Das Problem

APIs sind das Rueckgrat moderner Anwendungen, dennoch testen die meisten Teams nur den Happy Path — gueltige Anfrage rein, erwartete Antwort raus. Fehlende Tests fuer fehlerhafte Requests, Authentifizierungs-Randfaelle, Rate Limiting, Paginierungsgrenzen, parallele Schreibzugriffe und dutzende HTTP-Statuscodes werden uebersehen. Ein einziger ungetesteter API-Randfall kann zur Sicherheitsluecke oder zum Datenkorruptionsbug werden.

Der Prompt

Entwirf eine umfassende API-Testsuite fuer die folgenden Endpunkte. Jeden Weg abdecken, wie eine Anfrage erfolgreich sein, fehlschlagen oder sich unerwartet verhalten kann.

API-SPEZIFIKATION:
[OpenAPI/Swagger-Spec, Routendefinition einfuegen oder Endpunkt beschreiben]

AUTHENTIFIZIERUNG: [z.B. Bearer JWT, API-Key, OAuth 2.0, keine]
FRAMEWORK: [z.B. Supertest + Jest, httpx + pytest, REST Assured]

Tests fuer jede Kategorie generieren:

1. **Request-Validierung** — fehlende Felder, falsche Typen, zusaetzliche Felder, Grenzwerte, SQL/XSS-Payloads in Eingaben
2. **Authentifizierung & Autorisierung** — abgelaufenes Token, fehlendes Token, falsche Rolle, Token fuer anderen Benutzer
3. **Response-Schema** — Antwortformat fuer jeden Statuscode verifizieren (200, 201, 400, 401, 403, 404, 409, 422, 429, 500)
4. **Paginierung & Filterung** — erste Seite, letzte Seite, leere Ergebnisse, ungueltige Seitennummer, Sortierreihenfolge
5. **Idempotenz** — doppelte POST/PUT-Anfragen, parallele Aenderungen, ETag/If-Match-Handling
6. **Rate Limiting** — 429-Antwort und Retry-After-Header verifizieren
7. **Content Negotiation** — Accept-Header-Variationen, Zeichensatzhandling

Fuer jeden Test die vollstaendige HTTP-Anfrage (Methode, Pfad, Header, Body) und erwartete Antwort (Status, Header, Body-Form) angeben.

Beispielausgabe

describe('POST /api/users', () => {
  it('soll 201 mit Benutzerobjekt bei gueltiger Erstellung zurueckgeben', async () => {
    const res = await request(app).post('/api/users')
      .set('Authorization', `Bearer ${adminToken}`)
      .send({ email: 'neu@test.com', name: 'Testbenutzer', role: 'member' });
    expect(res.status).toBe(201);
    expect(res.body).toMatchObject({ email: 'neu@test.com', role: 'member' });
    expect(res.body.id).toBeDefined();
  });

  it('soll 409 zurueckgeben wenn E-Mail bereits existiert', async () => {
    const res = await request(app).post('/api/users')
      .set('Authorization', `Bearer ${adminToken}`)
      .send({ email: 'vorhanden@test.com', name: 'Duplikat', role: 'member' });
    expect(res.status).toBe(409);
    expect(res.body.error).toContain('existiert bereits');
  });
});

Wann verwenden

Beim Bauen neuer API-Endpunkte, beim Schreiben von Tests fuer undokumentierte Legacy-APIs oder bevor eine API fuer Drittanbieter geoeffnet wird. Unverzichtbar bevor eine API in Produktion geht — API-Bugs sind schwerer zu beheben, sobald Clients vom Verhalten abhaengen.

Profi-Tipps

• Von der OpenAPI-Spec ausgehen — die YAML/JSON-Spec einfuegen und KI bitten, Tests fuer jeden dokumentierten Response-Code zu generieren.
• Fehler-Response-Bodies testen — die meisten Teams pruefen nur Statuscodes. Assertieren, dass Fehlerantworten maschinenlesbare Fehlercodes enthalten.
• Sicherheits-Payloads einbeziehen — <script>alert(1)</script> und '; DROP TABLE users; -- in String-Felder einfuegen, um Eingabebereinigung zu verifizieren.
• Eine Postman-Collection generieren — mit “Konvertiere diese Tests in eine Postman Collection JSON” weiterarbeiten fuer manuelles Testing und Team-Sharing.