34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
# 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.
|