water/docs/superpowers/specs/2026-07-16-app-controller-concurrency-test-design.md

AppController Concurrency Test Design

Goal

Verify that one singleton AppController instance remains correct under concurrent calls without requiring live MySQL, Redis, MQTT, or OSS services.

Scope

Add a standalone unit concurrency test class covering three shared execution paths:

1. switchDevice: 32 threads, 3,200 total calls. Validate every generated startTime as yyyy-MM-dd HH:mm:ss.
2. uploadImage: 32 threads, 1,600 total calls across JPEG, PNG, GIF, WebP, and BMP. Validate each result and ensure no file type state leaks between calls.
3. editScheduleStatus: 32 threads, 640 total calls. Give every call a unique schedule/device pair and validate that its MQTT payload contains only the matching device and schedule detail.

Concurrency Model

Each test uses one fixed 32-thread executor and one shared controller instance. A ready latch ensures all workers are resident before a start latch releases them together. Every future has a bounded timeout so deadlocks and stalls fail the test instead of hanging the build.

All service collaborators are preconfigured Mockito mocks. Login state required by schedule ownership checks is scoped independently in each worker thread.

Success Criteria

• Every submitted operation completes within the timeout.
• No malformed timestamps, image validation errors, payload contamination, deadlocks, or unexpected exceptions occur.
• Invocation counts equal the requested operation totals.
• Existing water-app tests remain green.

Non-goals

• HTTP server throughput or latency benchmarking.
• Database transaction contention testing.
• Redis, MQTT broker, or OSS load testing.
• Production code changes unless a concurrency defect is reproduced.