Task 4-3: Integration Test - QUIT_GAME Rollback
Phase: 4 - Testing Priority: Medium Depends on: task-1-1 Reference:
docs/BountyHunter-Backend/details/feature-game-room-management/SPEC.md
Background
Khi QUIT_GAME xảy ra mid-game, cần rollback: room state xóa khỏi Redis, prize allocation reversed (DECREASE message), inventory restored.
Setup Note: Test cần: - Embedded Redis để track room state - Embedded JMS broker để verify
DECREASEmessages - Mock inventory/balance service để verify restore calls -task-1-1phải hoàn thành choRoomReasonCode.*constants
Test scenarios
Quit trước khi game start
- [ ] Create room →
QUIT_GAMEtrước khi nhậnGAME_STARTevent - [ ] Verify room xóa khỏi Redis (key không còn tồn tại)
- [ ] Verify không có
DECREASEmessage nào được gửi tới prize allocation queue - Clarification: "Không có prize deduction" nghĩa là chưa có INCREASE, nên không cần DECREASE để rollback
Quit sau khi game start (mid-game)
- [ ] Create room → đợi
GAME_STARTevent → một player gửiQUIT_GAME - [ ] Verify
DECREASEmessage được gửi tới đúng prize allocation queue - Clarification:
DECREASEmessage phải chứa đủ thông tin để reverse allocation (prizeId, amount, etc.) - [ ] Verify inventory/allocation của cả 2 players được restore
- Clarification: Cả player quit VÀ opponent đều được restore — không chỉ 1 trong 2
- [ ] Verify room state =
CANCELLEDtrong Redis (hoặc key bị xóa — check actual behavior trong code) - [ ] Verify opponent (player không quit) nhận broadcast
GAME_CANCELLEDevent
Quit khi chỉ có 1 player trong room (PVE)
- [ ] Create PVE Single Play room →
QUIT_GAME(chỉ 1 player) - [ ] Verify room được cleaned up trong Redis
- [ ] Verify life gauge deduction được reverted nếu đã deducted
- Clarification: Cần biết thời điểm nào life gauge bị deduct — trước hay sau
GAME_START. Check implementation để xác định flow.
Double quit (edge case)
- [ ] Cả 2 players gửi
QUIT_GAMEgần như đồng thời (e.g., trong 100ms) - [ ] Verify rollback chỉ xảy ra 1 lần (chỉ 1
DECREASEmessage, không duplicate) - Clarification: Cơ chế idempotency — kiểm tra implementation dùng Redis lock hay DB optimistic locking để tránh double rollback
Verification / Acceptance Criteria
- [ ] Scenario "quit trước game start": Redis key bị xóa + 0 DECREASE messages trong queue
- [ ] Scenario "quit mid-game": đúng 1 DECREASE message, cả 2 players được restore, opponent nhận GAME_CANCELLED
- [ ] Scenario "PVE single quit": life gauge restore được gọi đúng 1 lần (không duplicate, không bị skip)
- [ ] Scenario "double quit": đúng 1 rollback xảy ra (verify message count = 1, không = 2)
- [ ] Sau mỗi scenario, Redis không còn room data stale (cleanup đầy đủ)
- [ ] Tất cả tests pass không có race condition khi chạy nhiều lần liên tiếp
- [ ] Tests chạy được trong isolated environment với embedded Redis + JMS