Oleksandr Bezdieniezhnykh
3.0 KiB
Resilience & Performance Tests
Task: AZ-195_resilience_perf_tests Name: Resilience & Performance Tests Description: Implement resilience tests (DB recovery, malformed JWT, concurrency) and performance/resource limit tests Complexity: 5 points Dependencies: AZ-189_test_infrastructure, AZ-190_auth_tests Component: Blackbox Tests Tracker: AZ-195 Epic: AZ-188
Problem
The system's behavior under failure conditions, load, and resource limits is untested.
Outcome
- API survives database outage and recovers (NFT-RES-01)
- Malformed JWT tokens don't crash the system (NFT-RES-02)
- Concurrent hardware binding doesn't corrupt data (NFT-RES-03)
- Login latency stays under threshold (NFT-PERF-01)
- Resource download latency acceptable (NFT-PERF-02, NFT-PERF-03)
- Max file size boundary enforced (NFT-RES-LIM-01, NFT-RES-LIM-02)
- Memory stays bounded during encryption (NFT-RES-LIM-03)
Scope
Included
- Database loss/recovery resilience test
- Malformed JWT handling
- Concurrent hardware binding race condition
- Login endpoint performance under load
- Resource download performance (small + large files)
- Upload file size boundary (200 MB / 201 MB)
- Memory usage during large file encryption
Excluded
- User list performance under high user count (NFT-PERF-04 — deferred, requires bulk seed data)
Acceptance Criteria
AC-1: DB recovery Given the API is running When the database container is stopped and restarted Then the API returns errors during outage but recovers within 10s of DB restoration
AC-2: Malformed JWT Given various invalid Authorization headers When protected endpoints are called Then all return HTTP 401, system remains operational
AC-3: Concurrent hardware Given a user with no hardware When two concurrent hardware check requests arrive Then no data corruption; subsequent requests behave consistently
AC-4: Login latency Given 10 concurrent login requests When 100 total requests complete Then p95 latency < 500ms
AC-5: Max upload accepted Given a 200 MB file When POST /resources/testfolder Then HTTP 200
AC-6: Over-max upload rejected Given a 201 MB file When POST /resources/testfolder Then HTTP 413
Blackbox Tests
| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
|---|---|---|---|---|
| AC-1 | Running system | Stop/restart DB | Error then recovery | — |
| AC-2 | Various bad tokens | Protected endpoints | HTTP 401, no crash | — |
| AC-3 | Unbound user | Concurrent /resources/check | Consistent state | — |
| AC-4 | 10 concurrent users | 100 login requests | p95 < 500ms | — |
| AC-5 | 200 MB file | Upload | HTTP 200 | — |
| AC-6 | 201 MB file | Upload | HTTP 413 | — |
Risks & Mitigation
Risk 1: Docker container manipulation in tests
- Risk: Tests need to stop/start the DB container programmatically
- Mitigation: Use Docker SDK or shell commands from test fixture to control containers