Inventar Sync Generaltest: Bob-Szenario mit 10 Items, PATCH & WebSocket-Push

jreinemann-euris commented

2026-05-16 21:54:58 +00:00

(Migrated from github.com)

Kontext

Generaltest für den vollständigen Inventar-Sync-Flow. Testet das Zusammenspiel von Login, Inventar-Anlage, PATCH-Einzelupdate und WebSocket-Push-Benachrichtigung am Beispiel des Testbenutzers bob (Passwort: bob).

Das Szenario soll als neues Szenario 6 in run-integration-tests.ps1 eingebaut werden und deckt den typischen App-Lebenszyklus ab.

Haupt-Szenario: Bob legt ein Inventar mit 10 Artikeln an

Schritt 1 – Bob loggt sich ein

Bob sendet POST /api/auth/login mit { username: "bob", password: "bob" }
Antwort enthält accessToken, refreshToken und userId

Schritt 2 – Bob pusht 10 Artikel

Bob sendet PUT /api/inventory mit einem vollständigen InventoryDto:

3 Kategorien: Lebensmittel, Getränke, Hygiene
2 Lagerorte: Keller, Badezimmer
10 Artikel (zufällige UUID als id), z. B.:
1. Dosenbrot (Lebensmittel, Keller, qty=5)
2. Mineralwasser (Getränke, Keller, qty=24)
3. Thunfisch (Lebensmittel, Keller, qty=8)
4. Nudeln (Lebensmittel, Keller, qty=3)
5. Toilettenpapier (Hygiene, Badezimmer, qty=12)
6. Seife (Hygiene, Badezimmer, qty=4)
7. Müsliriegel (Lebensmittel, Keller, qty=20)
8. Apfelsaft (Getränke, Keller, qty=6)
9. Kerzen (Lebensmittel, Keller, qty=10)
10. Erste-Hilfe-Pflaster (Hygiene, Badezimmer, qty=2)

Assert: GET /api/inventory → 10 Items, 3 Kategorien, 2 Lagerorte

Schritt 3 – Bob ändert einen bestehenden Artikel (PATCH)

Bob sendet PATCH /api/inventory/items/{id} für Dosenbrot → quantity = 10
Assert: GET /api/inventory → Dosenbrot qty = 10

Schritt 4 – Bob fügt einen weiteren Artikel hinzu (PUT mit 11 Items)

Bob pusht das komplette Inventar erneut, diesmal mit 11 Items (neu: Salzcracker)
Assert: GET /api/inventory → 11 Items

Schritt 5 – Server-seitige Änderung löst WebSocket-Push aus

Bob öffnet eine WebSocket-Verbindung: ws://<host>/ws/sync?token=<bobToken>
Ein zweiter Client (oder Admin) sendet PATCH /api/inventory/items/{dosenbroId} → quantity = 15
Bob empfängt auf seinem WebSocket ein Event vom Typ inventory_updated mit der itemId
Assert: Empfangenes Event enthält type = "inventory_updated" und korrekte itemId

Schritt 6 – Full-Sync-Push bei PUT

Zweiter Client sendet PUT /api/inventory (beliebiges Inventar für Bobs userId)
Assert: Bob empfängt WebSocket-Event type = "full_sync_required"

Weitere Testfälle (nach dem Haupt-Szenario)

#	Name	Beschreibung
T1	`bob_patchNonExistentItem_returns404`	PATCH auf eine unbekannte Item-ID → HTTP 404
T2	`bob_pushEmptyInventory_clearsAll`	PUT mit leeren Listen → GET liefert leeres Inventar
T3	`bob_putOverwritesPreviousData`	Zwei PUTs hintereinander → Zweites Inventar gewinnt vollständig
T4	`bob_websocketReceivesOwnPatch`	Bob patcht selbst → bekommt trotzdem `inventory_updated`
T5	`bob_cannotSeeAlice_inventory`	Bob und Alice haben separate Inventare (User-Isolation)
T6	`bob_invalidToken_returns401`	Ungültiger Token → PATCH und GET liefern 401
T7	`bob_multipleWebSocketSessions`	Bob öffnet 2 WS-Verbindungen → beide erhalten das Event
T8	`bob_patchAfterDisconnect_noError`	Bob disconnected, dritter Client patcht → kein Serverfehler

Umsetzungshinweise

Testumgebung: run-integration-tests.ps1 gegen laufenden Server (lokal oder VPS)
Bob existiert bereits auf dem VPS (Seeding beim Server-Start via authorized_keys.pub / Admin-Init)
Bob-Token über POST /api/auth/login ermitteln – kein hartcodiertes JWT
WebSocket-Tests analog zu Szenario 5 (Parallele Sessions) mit Open-WebSocket / Receive-WsMessages
Item-IDs als [System.Guid]::NewGuid() generieren, damit Tests idempotent sind
Keine Unit-Test-Ebene nötig – alles als Integrationstests gegen echten Server; Unit-Tests für PATCH-Routing existieren bereits in EndToEndSyncTest.kt
Nach jedem Szenario Cleanup via PUT /api/inventory mit leeren Listen (oder neuer DB-Zustand ist ok)

Akzeptanzkriterien

Szenario 6 (Bob Inventar Generaltest) in run-integration-tests.ps1 implementiert
Alle 6 Hauptschritte laufen durch ([PASS])
Mindestens 4 der 8 weiteren Testfälle (T1–T8) implementiert und grün
.\run-integration-tests.ps1 läuft vollständig ohne [FAIL]
WebSocket-Push für inventory_updated und full_sync_required geprüft

## Kontext Generaltest für den vollständigen Inventar-Sync-Flow. Testet das Zusammenspiel von Login, Inventar-Anlage, PATCH-Einzelupdate und WebSocket-Push-Benachrichtigung am Beispiel des Testbenutzers **bob** (Passwort: `bob`). Das Szenario soll als neues Szenario 6 in `run-integration-tests.ps1` eingebaut werden und deckt den typischen App-Lebenszyklus ab. --- ## Haupt-Szenario: Bob legt ein Inventar mit 10 Artikeln an ### Schritt 1 – Bob loggt sich ein - Bob sendet `POST /api/auth/login` mit `{ username: "bob", password: "bob" }` - Antwort enthält `accessToken`, `refreshToken` und `userId` ### Schritt 2 – Bob pusht 10 Artikel Bob sendet `PUT /api/inventory` mit einem vollständigen `InventoryDto`: - 3 Kategorien: `Lebensmittel`, `Getränke`, `Hygiene` - 2 Lagerorte: `Keller`, `Badezimmer` - 10 Artikel (zufällige UUID als `id`), z. B.: 1. Dosenbrot (Lebensmittel, Keller, qty=5) 2. Mineralwasser (Getränke, Keller, qty=24) 3. Thunfisch (Lebensmittel, Keller, qty=8) 4. Nudeln (Lebensmittel, Keller, qty=3) 5. Toilettenpapier (Hygiene, Badezimmer, qty=12) 6. Seife (Hygiene, Badezimmer, qty=4) 7. Müsliriegel (Lebensmittel, Keller, qty=20) 8. Apfelsaft (Getränke, Keller, qty=6) 9. Kerzen (Lebensmittel, Keller, qty=10) 10. Erste-Hilfe-Pflaster (Hygiene, Badezimmer, qty=2) **Assert:** `GET /api/inventory` → 10 Items, 3 Kategorien, 2 Lagerorte ### Schritt 3 – Bob ändert einen bestehenden Artikel (PATCH) - Bob sendet `PATCH /api/inventory/items/{id}` für Dosenbrot → `quantity = 10` - **Assert:** `GET /api/inventory` → Dosenbrot qty = 10 ### Schritt 4 – Bob fügt einen weiteren Artikel hinzu (PUT mit 11 Items) - Bob pusht das komplette Inventar erneut, diesmal mit 11 Items (neu: `Salzcracker`) - **Assert:** `GET /api/inventory` → 11 Items ### Schritt 5 – Server-seitige Änderung löst WebSocket-Push aus - Bob öffnet eine WebSocket-Verbindung: `ws://<host>/ws/sync?token=<bobToken>` - Ein **zweiter Client** (oder Admin) sendet `PATCH /api/inventory/items/{dosenbroId}` → `quantity = 15` - Bob empfängt auf seinem WebSocket ein Event vom Typ `inventory_updated` mit der `itemId` - **Assert:** Empfangenes Event enthält `type = "inventory_updated"` und korrekte `itemId` ### Schritt 6 – Full-Sync-Push bei PUT - Zweiter Client sendet `PUT /api/inventory` (beliebiges Inventar für Bobs userId) - **Assert:** Bob empfängt WebSocket-Event `type = "full_sync_required"` --- ## Weitere Testfälle (nach dem Haupt-Szenario) | # | Name | Beschreibung | |---|------|--------------| | T1 | `bob_patchNonExistentItem_returns404` | PATCH auf eine unbekannte Item-ID → HTTP 404 | | T2 | `bob_pushEmptyInventory_clearsAll` | PUT mit leeren Listen → GET liefert leeres Inventar | | T3 | `bob_putOverwritesPreviousData` | Zwei PUTs hintereinander → Zweites Inventar gewinnt vollständig | | T4 | `bob_websocketReceivesOwnPatch` | Bob patcht selbst → bekommt trotzdem `inventory_updated` | | T5 | `bob_cannotSeeAlice_inventory` | Bob und Alice haben separate Inventare (User-Isolation) | | T6 | `bob_invalidToken_returns401` | Ungültiger Token → PATCH und GET liefern 401 | | T7 | `bob_multipleWebSocketSessions` | Bob öffnet 2 WS-Verbindungen → beide erhalten das Event | | T8 | `bob_patchAfterDisconnect_noError` | Bob disconnected, dritter Client patcht → kein Serverfehler | --- ## Umsetzungshinweise - **Testumgebung:** `run-integration-tests.ps1` gegen laufenden Server (lokal oder VPS) - **Bob existiert bereits** auf dem VPS (Seeding beim Server-Start via `authorized_keys.pub` / Admin-Init) - Bob-Token über `POST /api/auth/login` ermitteln – kein hartcodiertes JWT - WebSocket-Tests analog zu Szenario 5 (Parallele Sessions) mit `Open-WebSocket` / `Receive-WsMessages` - Item-IDs als `[System.Guid]::NewGuid()` generieren, damit Tests idempotent sind - **Keine Unit-Test-Ebene nötig** – alles als Integrationstests gegen echten Server; Unit-Tests für PATCH-Routing existieren bereits in `EndToEndSyncTest.kt` - Nach jedem Szenario Cleanup via `PUT /api/inventory` mit leeren Listen (oder neuer DB-Zustand ist ok) --- ## Akzeptanzkriterien - [ ] Szenario 6 (Bob Inventar Generaltest) in `run-integration-tests.ps1` implementiert - [ ] Alle 6 Hauptschritte laufen durch (`[PASS]`) - [ ] Mindestens 4 der 8 weiteren Testfälle (T1–T8) implementiert und grün - [ ] `.\run-integration-tests.ps1` läuft vollständig ohne `[FAIL]` - [ ] WebSocket-Push für `inventory_updated` und `full_sync_required` geprüft

Inventar Sync Generaltest: Bob-Szenario mit 10 Items, PATCH & WebSocket-Push #62