Backend & APIs testen

Backend-Tests in XAIO laufen typischerweise als pytest im Workspace-Container. Der Agent legt eine tests/ Struktur an, falls noch nicht vorhanden, und kann Unit-, Integration- und Smoke-Tests schreiben.

Endpoint-Tests

Alle Endpunkte gleichzeitig testen:

> Teste mir alle FastAPI-Endpoints. Für jeden: 200, 400, 401, 404 wo zutreffend. Schreib das in tests/test_endpoints.py und lass es laufen.

Was passiert: Der Agent liest deine Routen aus main.py, generiert pro Route Test-Cases mit gültigem JWT, ungültigem Payload, fehlendem Auth-Header — und führt sie via pytest -v aus.

Pro Endpoint detailliert:

> Schreib einen Test für POST /api/projects — er muss prüfen dass:

> 1. Ein eingeloggter User ein Projekt anlegen kann

> 2. Plan-Limit-Verletzung 402 zurückgibt

> 3. Ungültiger pipeline_type 400 zurückgibt

Datenbank-Tests

Migration testen:

> Teste die V075-Migration. Roll sie an, leg ein paar Beta-Bewerbungen an, prüf dass alle Felder korrekt persistieren. Roll dann zurück und prüf dass die Tabelle weg ist.

Constraint-Tests:

> Schreib einen Test der prüft, dass status nur 'pending', 'approved', 'rejected', 'waitlist' oder 'contacted' sein kann. Andere Werte müssen einen IntegrityError werfen.

Mock vs. Real-DB

Per Default nutzt der Agent eine echte lokale Postgres für Backend-Tests (siehe Memory-Eintrag *integration tests must hit a real database, not mocks*).

Wenn du explizit Mocks willst:

> Mock die DB-Calls für diesen Test — ich will isoliert nur die Service-Logik prüfen, nicht die Persistenz.

Externe APIs (Stripe, Brevo, GitHub)

Diese werden immer gemockt, niemals real aufgerufen während Tests:

> Teste den Stripe-Webhook-Handler. Mock einen payment_intent.succeeded-Event, prüf dass die Subscription auf active gesetzt wird, Idempotency-Test mit doppelter Event-ID.

Property-Based Testing

Für komplexe Invarianten kann der Agent hypothesis nutzen:

> Verwende hypothesis um zu prüfen, dass der Slug-Generator IMMER URL-safe ist, egal welcher Input kommt. Probier auch Unicode, Emojis, sehr lange Strings.

Integration-Tests mit Containern

Für Tests die einen echten Postgres + Redis brauchen:

> Schreib einen Integration-Test der einen User anlegt, ein Projekt erstellt, es published, und prüft dass alle 6 Cleanup-Schritte funktionieren wenn er es wieder löscht.

Coverage & CI

> Lass pytest --cov=services --cov-report=html laufen und sag mir wo wir unter 80% Coverage sind.

Der Agent kann auch eine GitHub-Actions-Workflow-Datei generieren:

> Schreib einen .github/workflows/test.yml, der bei jedem PR die Backend-Tests ausführt — Postgres als Service-Container.