a38beadb8e
All checks were successful
Deploy yourpart (blue-green) / deploy (push) Successful in 1m41s
111 lines
3.2 KiB
Markdown
111 lines
3.2 KiB
Markdown
# Falukant Smoke-Test: Tod -> Erbwechsel -> UI-Status
|
|
|
|
Dieser Smoke-Test validiert den kritischen Ablauf:
|
|
|
|
- Spieler-Charakter stirbt
|
|
- Erbe wird gesetzt
|
|
- alte charakterbezogene Daten sind bereinigt
|
|
- UI bekommt verlässlich den Status-Refresh
|
|
|
|
## Ziel
|
|
|
|
Verhindern, dass nach Tod/Erbe ein Mischzustand entsteht
|
|
(z. B. Erben-Bild, aber alte Statusdaten des verstorbenen Charakters).
|
|
|
|
## Voraussetzungen
|
|
|
|
- Daemon läuft mit aktuellen Änderungen.
|
|
- Zugriff auf DB (psql).
|
|
- Zugriff auf WebSocket-Eventstream oder Daemon-Log.
|
|
- Ein Test-User mit:
|
|
- aktivem Spieler-Charakter (`user_id` gesetzt),
|
|
- mindestens einem potenziellen Erben in `child_relation`.
|
|
|
|
## Testfall A: Tod über `UserCharacterWorker` (health <= 0)
|
|
|
|
1. Testkandidaten wählen:
|
|
|
|
```sql
|
|
SELECT c.id AS character_id, c.user_id
|
|
FROM falukant_data.character c
|
|
WHERE c.user_id IS NOT NULL
|
|
ORDER BY c.updated_at DESC
|
|
LIMIT 20;
|
|
```
|
|
|
|
2. Einen Charakter künstlich auf `health = 0` setzen:
|
|
|
|
```sql
|
|
UPDATE falukant_data.character
|
|
SET health = 0, updated_at = NOW()
|
|
WHERE id = <CHARACTER_ID>;
|
|
```
|
|
|
|
3. Worker laufen lassen (Death-Check oder nächster Verarbeitungstakt).
|
|
|
|
4. WebSocket/Log prüfen, erwartet:
|
|
- `CharacterDeath` mit altem `character_id`
|
|
- `falukantUpdateStatus` mit `user_id` des betroffenen Spielers
|
|
|
|
5. DB prüfen, erwartet:
|
|
|
|
```sql
|
|
-- alter Charakter weg
|
|
SELECT 1
|
|
FROM falukant_data.character
|
|
WHERE id = <CHARACTER_ID>;
|
|
|
|
-- Spieler zeigt auf Erben
|
|
SELECT c.id, c.user_id
|
|
FROM falukant_data.character c
|
|
WHERE c.user_id = <USER_ID>;
|
|
```
|
|
|
|
```sql
|
|
-- Todes-Cleanup (sollte leer sein)
|
|
SELECT COUNT(*) FROM falukant_data.knowledge WHERE character_id = <CHARACTER_ID>;
|
|
SELECT COUNT(*) FROM falukant_data.debtors_prism WHERE character_id = <CHARACTER_ID>;
|
|
SELECT COUNT(*) FROM falukant_data.political_office WHERE character_id = <CHARACTER_ID>;
|
|
SELECT COUNT(*) FROM falukant_data.election_candidate WHERE character_id = <CHARACTER_ID>;
|
|
```
|
|
|
|
```sql
|
|
-- politische Ämter historisiert (falls vorher vorhanden)
|
|
SELECT *
|
|
FROM falukant_log.political_office_history
|
|
WHERE character_id = <CHARACTER_ID>
|
|
ORDER BY end_date DESC
|
|
LIMIT 5;
|
|
```
|
|
|
|
Passkriterium:
|
|
- alter Charakter gelöscht,
|
|
- Nachfolger gesetzt,
|
|
- Cleanup-Counts = 0,
|
|
- `falukantUpdateStatus` gesendet.
|
|
|
|
## Testfall B: Tod über `EventsWorker`
|
|
|
|
Der gleiche Prüfsatz wie in Testfall A, aber mit Tod aus Event-Pfad.
|
|
|
|
Hinweis:
|
|
- Falls kein reproduzierbares Zufallsereignis vorliegt, kann derselbe technische Endzustand
|
|
pragmatisch über A validiert werden.
|
|
- Zusätzlicher Fokus hier: auch im Event-Pfad müssen Cleanup + Status-Refresh identisch sein.
|
|
|
|
## UI-Schnellcheck
|
|
|
|
Nach Eintreffen von `falukantUpdateStatus`:
|
|
|
|
- Avatar/Bild entspricht dem Erben.
|
|
- Statusdaten (Familie/Politik/bezogene Anzeigen) zeigen keine Relikte des Verstorbenen.
|
|
- Kein inkonsistenter Mischzustand nach manuellem Reload.
|
|
|
|
## Regression-Checkliste
|
|
|
|
- [ ] `CharacterDeath` kommt genau für den verstorbenen Charakter.
|
|
- [ ] `falukantUpdateStatus` kommt nach Erbwechsel für den betroffenen User.
|
|
- [ ] `knowledge`/`debtors_prism`/`political_office`/`election_candidate` sind bereinigt.
|
|
- [ ] `political_office_history` enthält entfernte Ämter (falls vorhanden).
|
|
- [ ] UI bleibt konsistent (Bild + Status gehören zum selben Charakter).
|