Sluijsens
9ab30fe2a6
Unit suites already passed individually; this is the full solution together plus what none of them could check alone: two real hosts talking to each other, a slave API key encrypted by one process and decrypted by the next one after a restart, and headers landing on actual static files instead of a simulated response.
1.4 KiB
1.4 KiB
Unit Test Execution
Run Unit Tests
1. Execute All Unit Tests
dotnet test SlpModularCms.sln -c Release
cd frontend
pnpm run test
2. Review Test Results
- Expected — backend: 372 tests pass, 0 failures (Core 196, Availability 82, Master 57, Identity 37).
SlpModularCms.ApiandSlpModularCms.Api.Slavehave no test project by convention (CLAUDE.md) — their behaviour is covered by this stage's live integration verification instead - Expected — frontend: 237 tests pass, 0 failures, across 38 test files
- Test Coverage: no coverage threshold is enforced (D-10 — deliberate decision, not an oversight)
- Test Report Location: console output;
dotnet testandvitest runboth exit non-zero on any failure, which is what the CI gates (U5) act on
3. Fix Failing Tests
If tests fail:
- Identify which project/file failed from the console output
- Since every unit was already build-and-test-verified individually during Code Generation, a failure here means a cross-unit interaction broke something that passed in isolation — check what changed in the units involved
- Fix and rerun until green
Result at This Stage (2026-07-28)
- Backend: 372 passed, 0 failed
- Frontend: 237 passed, 0 failed
- Both counts are unchanged from the Round 2 and Round 3 per-unit baselines — confirms the full suite passes together, not just in isolation