Files
annotations/_docs/02_tasks/todo/AZ-573_test_resource_limits.md
T
Oleksandr Bezdieniezhnykh cf632d9e2e [AZ-563] Decompose blackbox tests into AZ-564..574 task specs
Step 5 of autodev existing-code flow. Epic AZ-563 plus 11 atomic
tasks covering all 67 test scenarios from
_docs/02_document/tests/* exactly once:

- AZ-564 test infrastructure (xUnit + Docker + mock JWKS + dataseed)
- AZ-565..568 functional positive (FT-P-01..22)
- AZ-569..570 functional negative (FT-N-01..16)
- AZ-571 security (NFT-SEC-01..10)
- AZ-572 resilience (NFT-RES-01..06)
- AZ-573 resource limits (NFT-RES-LIM-01..06)
- AZ-574 performance (NFT-PERF-*)

_dependencies_table.md records the cross-check vs traceability
matrix (22 + 16 + 29 = 67 scenarios, no overlaps, no gaps; deferred
items remain deferred per matrix). All task headers carry their
Jira IDs (tracker: jira). Autodev state advanced to Step 6
(Implement Tests).

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-14 21:13:53 +03:00

2.7 KiB

Resource-limit tests (NFT-RES-LIM-01..06)

Task: AZ-573 Name: Resource-limit tests Description: Implement xUnit tests for the 6 resource-limit scenarios: sustained-load process memory, single-file upload boundary, outbox depth under broker outage, disk usage by images_dir, concurrent SSE subscribers, migration on cold-start cost. Complexity: 3 points Dependencies: AZ-564 (test infrastructure) Component: Blackbox Tests → Resource Limits Tracker: jira Epic: AZ-563

Scenarios Covered

Test ID Source What it asserts
NFT-RES-LIM-01 _docs/02_document/tests/resource-limit-tests.md Sustained-load process memory stays within configured envelope.
NFT-RES-LIM-02 same Single-file upload boundary — 1, 10, 50, 100, 256, 512 MB. Uses LargePayloadFixture synthetic JPEGs.
NFT-RES-LIM-03 same Outbox queue depth bounded under broker outage. Depth never exceeds documented ceiling for ≥ 30 min run.
NFT-RES-LIM-04 same Disk usage by images_dir over many distinct uploads. Stays under documented HW-02 budget.
NFT-RES-LIM-05 same Concurrent SSE subscribers — process-memory boundary. N concurrent subscribers don't push memory past envelope.
NFT-RES-LIM-06 same Migration on cold-start cost. Time-to-/health=200 from cold start within the documented boot budget.

System Under Test Boundary

  • HTTP only.
  • Memory + disk metrics read from docker stats (out-of-band, runner-only). Marked [Trait("docker_stats", "true")].
  • NFT-RES-LIM-02 uses LargePayloadFixture to generate synthetic JPEGs at runtime; never committed to repo.
  • NFT-RES-LIM-03 long-running (30 min smoke variant); the nightly profile runs the full 30 min, the standard profile runs a 5-min smoke proxy.
  • NFT-RES-LIM-05 spawns N parallel SSE subscribers via Parallel.For + per-subscriber HttpClient.

Acceptance Criteria

AC-1: Every scenario passes per its spec.

AC-2: Smoke vs nightly profile distinction Given a profile environment variable E2E_RUN_PROFILE=functional (default), When NFT-RES-LIM-03 runs, Then it executes a 5-min smoke proxy (not the 30-min full run); under E2E_RUN_PROFILE=performance, it runs the full 30 min.

AC-3: Memory + disk readings have measurement uncertainty noted Given docker stats is the measurement source, When the test records a memory or disk reading, Then the result includes a tolerance margin (e.g., ± 50 MB for memory, ± 100 MB for disk) per the documented results_report.md tolerance.

Constraints

  • AAA pattern.
  • [Trait("traces_to", "AC-N-03, AC-N-05, HW-02, HW-03")] plus per-test specific traces.
  • Long-running tests [Fact(Timeout = ?)] per documented duration; never hang the runner.