Postman API-Testkonzept

Ziel: Postman als zweite Testschicht neben Emulator-Tests nutzen, um Backend-Flows gegen Firestore, Cloud Functions und ausgewählte Admin-Schnittstellen reproduzierbar zu prüfen.

Zielbild

Postman soll bei easySale nicht nur Security-Checks abdecken, sondern als praktisches API-Testwerkzeug für folgende Szenarien dienen:

• Artikel anlegen, lesen, ändern und löschen
• Kunden anlegen, lesen, ändern und löschen
• Bestellungen anlegen und verifizieren
• Berechtigungen und Claims prüfen
• Admin-/System-Flows smoke-testen
• Negative Tests gegen Regeln, Validierung und Statuswechsel

Die Leitlinie ist klar:

• Emulator-Tests bleiben das Hauptwerkzeug für harte Geschäftslogik, Trigger und deterministische Regressionen.
• Postman ergänzt diese Tests für manuelle Prüfung, Freigabe-Checks, kleinere Integrationsläufe und reproduzierbare API-Szenarien.
• Newman macht die wichtigsten Collection-Flows im CI ausführbar.

Was Postman hier leisten soll

1. Fixture- und Setup-Tests

Postman soll Testdaten anlegen, die danach in anderen Requests weiterverwendet werden.

Typische Beispiele:

• Test-Artikel mit Preis, Varianten, Sichtbarkeit und Aktiv-Status anlegen
• Test-Kunden mit Nummer, Land, Kategorie und Freigaben anlegen
• Test-Benutzer oder Test-Claims vorbereiten
• Referenzdaten und Default-Werte setzen

2. Business-Flow-Tests

Diese Requests prüfen komplette Abläufe statt nur einzelne Funktionen.

Typische Beispiele:

• Artikel anlegen und anschließend auslesen
• Kunden anlegen und Zuordnungen verifizieren
• Order erstellen und Ergebnis inklusive Nummer, Betrag und Positionen prüfen
• Folgeaktionen wie Statuswechsel, Benachrichtigungen oder Trigger-Auswirkungen prüfen

3. Sicherheits- und Regeltests

Postman bleibt ein guter Ort für kleine, reproduzierbare Security-Checks.

Typische Beispiele:

• Unautorisierte Requests werden abgelehnt
• Falsche Rollen oder fehlende Claims blockieren Schreibzugriffe
• Ungültige Payloads werden sauber zurückgewiesen
• Daten bleiben in der richtigen Mandanten- oder Kunden-Sphäre

Nicht-Ziel

Postman soll nicht die Unit- und Emulator-Tests ersetzen.

Nicht hier abdecken:

• komplexe Preis- und Rundungslogik
• Trigger-Ketten mit vielen DB-Interaktionen
• zeitabhängige Berechnungen wie Liefertage oder Feiertage
• tiefes Mocking von Firebase Runtime-Verhalten

Diese Dinge bleiben in den bestehenden Functions- und Emulator-Tests.

Empfohlene Architektur

Collections

Ich würde die Collection in klar getrennte Ordner aufteilen:

Ordner	Zweck
00-auth	Login, Token-Handling, Umgebungscheck
10-setup	Seed-Daten, Basisdaten, Cleanup
20-articles	Artikel anlegen, ändern, lesen, löschen
30-customers	Kunden anlegen, ändern, lesen, löschen
40-orders	Bestellungen, Order-Status, Verifikation
50-admin	Admin-Aktionen, Rollen, Sonderflüsse
90-smoke	Kleine End-to-End-Prüfung vor Release

Environments

Ich würde drei Umgebungen anlegen:

Environment	Zweck	Sicherheit
local-emulator	Gegen Firebase Emulatoren testen	ungefährlich, destruktiv erlaubt
staging	Vor Release gegen Testsystem	produktionsnah, aber getrennte Daten
production-readonly	Nur sehr kleine Smoke-Checks	keine Schreibtests

Variablen

Die Collection soll mit klaren Variablen arbeiten:

Variable	Beispiel	Zweck
baseUrl	Emulator- oder Cloud-URL	Zielsystem
projectId	test-project	Firestore- und Auth-Bezug
apiKey	Firebase Web API Key	Auth-Login via REST
idToken	JWT	Requests authentifizieren
refreshToken	Refresh Token	Token erneuern
customerId	generierte ID	Folge-Requests
articleId	generierte ID	Folge-Requests
orderId	generierte ID	Verifikation

Auth-Konzept

Für Postman würde ich einen einheitlichen Auth-Flow verwenden:

1. Login mit Test-Account pro Environment.
2. idToken in der Environment speichern.
3. Alle Requests senden Authorization: Bearer {{idToken}}.
4. Wenn der Token abläuft, automatisch per Pre-request-Script erneuern.

Für den Emulator können wir einen separaten Test-Account oder Emulator-Auth nutzen. Für Staging braucht es ein klares, nicht produktives Testkonto mit festen Rollen.

Wichtig:

• Keine echten Benutzerpasswörter in geteilten Collections.
• Secrets nur in lokalen oder geschützten Environments.
• Produktion nur mit Accounts, die ausdrücklich für Smoke-Tests vorgesehen sind.

Datenstrategie

Prinzipien

• Jeder Test ist möglichst selbstgenügsam.
• Jeder Test erzeugt seine eigenen IDs.
• Jeder Test räumt am Ende auf, wenn er schreibt.
• Fixture-Daten bleiben klein und nachvollziehbar.
• Unklare Seiteneffekte werden nicht toleriert.

Testdaten-Klassen

Klasse	Beispiel	Nutzung
Basis-Fixtures	ein Standard-Kunde, ein Standard-Artikel	Smoke-Tests
Fach-Fixtures	Varianten, Länder, Kategorien, Preisstaffeln	Fachflüsse
Fehler-Fixtures	gesperrter Artikel, fehlende Variante, falsche Rolle	Negativtests
Cleanup-Daten	temporäre Test-IDs	Aufräumen nach Lauf

Welche Flows ich aufnehmen würde

Artikel

• Artikel anlegen mit Pflichtfeldern
• Artikel mit Varianten anlegen
• Artikel ändern und erneut lesen
• Artikel löschen und prüfen, ob Folgeobjekte sauber reagieren
• gesperrte oder inaktive Artikel ablehnen

Kunden

• Kunden mit Nummer, Land und Kategorie anlegen
• Kunden aktualisieren
• Kundenfreigaben prüfen
• Kunden ohne Berechtigung blockieren
• Kundenlöschung und Folgeeffekte prüfen

Orders

• Order mit gültigem Kunden und Artikel anlegen
• Order mit Varianten und Mengen anlegen
• Order mit fehlerhaften Positionen ablehnen
• Ordernummer und Betrag verifizieren
• Order-Folgeobjekte oder Trigger-Effekte prüfen

Admin und System

• Rollenwechsel nur mit berechtigtem Account
• System- oder Job-Endpoints nur mit Admin-Berechtigung
• Smoke-Tests für wichtige Backend-Checks

Konkretes Collection-Design

Request-Reihenfolge für einen typischen Lauf

1. Auth holen.
2. Basisdaten anlegen.
3. Artikel anlegen.
4. Kunden anlegen.
5. Order anlegen.
6. Ergebnis aus Firestore oder API zurücklesen.
7. Cleanup ausführen.

Beispielhafte Assertions

Postman-Tests sollten nicht nur Statuscodes prüfen, sondern auch fachliche Aussagen:

• Datensatz wurde angelegt
• Referenz-ID wurde gespeichert
• Pflichtfelder sind vorhanden
• Beträge und Status sind korrekt
• Schreibzugriff wurde nur für erlaubte Rollen zugelassen

Newman im CI

Ich würde Newman für zwei Arten von Läufen einsetzen:

1. Smoke-Lauf bei jedem wichtigen Merge

• 5 bis 10 Kernrequests
• nur Happy Path und wichtigste Negativfälle
• Ziel: schneller Rückkanal

2. Voller API-Lauf vor Release

• alle relevanten Collection-Ordner
• inklusive Cleanup und Negativtests
• Ziel: nachvollziehbare Freigabe gegen Staging

Empfohlene Umsetzung in Stufen

Phase 1: Grundgerüst

• Collection-Struktur anlegen
• Environment-Variablen definieren
• Auth-Flow einbauen
• 3 bis 5 Smoke-Requests bauen

Phase 2: Fachflüsse

• Artikel anlegen und verifizieren
• Kunden anlegen und verifizieren
• Orders anlegen und verifizieren
• Negative Tests ergänzen

Phase 3: CI-Härtung

• Newman-Skript in CI integrieren
• Staging-Run automatisieren
• Smoke-Run für Pull Requests oder Release-Kandidaten definieren

Meine Empfehlung für easySale

Ich würde das Setup bewusst zweigleisig bauen:

1. Emulator-Tests für belastbare Backend-Logik, Trigger und Regressionen.
2. Postman/Newman für API-Integration, manuelle Freigabe und schnelle End-to-End-Checks.

Das ist die pragmatischste Aufteilung, weil Postman sehr gut für reproduzierbare API-Flows ist, aber bei tiefer Geschäftslogik und Firebase-Triggern schnell unhandlich wird.

Nächster sinnvoller Schritt

Wenn du willst, kann ich als Nächstes direkt die konkrete Postman-Struktur ausarbeiten:

• Collection-Namen und Ordner
• Environment-Variablen pro Umgebung
• Auth-Flow als Pre-request-Script
• erste Requests für Artikel, Kunden und Orders
• Newman-Aufruf für CI