Caseworker — tests¶
The caseworker portal is the oldest and largest board, and the one whose end-to-end journeys exercise the full Operaton stack.
Frontend: 43 files · 329 tests. E2E: 5 specs · 12 tests.
Frontend¶
The CaseworkerDashboard/ directory is not only this board's: it is the
shared section-component library, reused across three of the four V2
dashboards. Changes there ripple, which is why it carries 185 tests across 26
files on its own.
| Area | Files | Tests |
|---|---|---|
components/CaseworkerDashboard (shared section library) |
26 | 185 |
components/CaseworkerDashboardV2 |
15 | 116 |
pages/caseworker-v2 (modes.config) |
1 | 21 |
pages/CaseworkerDashboardV2.test.tsx |
1 | 7 |
Largest files:
| File | Tests | Covers |
|---|---|---|
CaseworkerDashboardV2/SectionRouter.test.tsx |
28 | Section routing and the shell's state machine |
CaseworkerDashboardV2/regelsimulatie/simEngine.test.ts |
22 | The deterministic budget-exhaustion simulator |
pages/caseworker-v2/modes.config.test.ts |
21 | Mode configuration, a pure data module |
CaseworkerDashboard/TaskFormViewer.test.tsx |
14 | Rendering and submitting an Operaton task form |
CaseworkerDashboard/IouFeedbackSection.test.tsx |
10 | Feedback capture |
CaseworkerDashboard/IouGebruiksscenarioSection.test.tsx |
10 | Usage-scenario section |
CaseworkerDashboard/ProfielSection.test.tsx |
10 | Profile data |
CaseworkerDashboard/McpChatSection.test.tsx |
9 | The MCP chat surface |
CaseworkerDashboard/ProcessStepsTimeline.test.tsx |
9 | Process step timeline |
Coverage: components/CaseworkerDashboard 86.33%,
components/CaseworkerDashboardV2 81.27%, and the regelsimulatie
sub-directory 97.66%.
The simulator carries a real performance budget
simEngine.ts must process the default 3,150-application population in
under 250ms. That assertion does not run in the default suite — it
lives in simEngine.perf.test.ts and runs via npm run test:perf, without
file parallelism, as its own CI step. The reasoning is on
Overview.
E2E¶
Five specs, twelve tests. Measured 20 August 2026 against v2026.08.20: 12
tests, 12 passed, 0 failed, 0 flaky, 0 skipped, 54.1s. Not re-run on
22 August — the PA cockpit specs added alongside them were measured separately,
bringing the e2e/ directory to 19 tests in total.
That run was against the corrected e2e-fixtures BPMNs redeployed from the
Linked Data Explorer, which confirms that chain end to end.
| Spec | Covers |
|---|---|
smoke.spec.ts |
App loads at /, LoginChoice renders, no console errors |
login-redirect.spec.ts |
One test per role (citizen / caseworker / infra / woo / PA) against the Flevoland tenant, driving the real Keycloak hosted login — 5 tests |
protected-route.spec.ts |
Cross-role ProtectedRoute redirect behaviour — 2 tests |
caseworker-journey.spec.ts |
A citizen submits a real Kapvergunning request via Operaton/DMN; the caseworker claims and completes both resulting tasks — a genuinely finalised roundtrip |
zorgtoeslag-journey.spec.ts |
A second deep journey — a commercial-org citizen submits a Zorgtoeslag claim, and the toeslagen caseworker completes both steps |
tenant-isolation.spec.ts |
A real cross-tenant fixture — confirms a wrong-tenant caseworker does not see a task, and the right one does |
tenant-isolation.spec.ts is the empirical proof of the tenancy-scoping
behaviour described in
Processes → Tenancy and
Tasks → Visibility: a task raised under
one tenant is visible only to that tenant's caseworker.
What the suite needs running, and why it fails fast rather than starting anything itself, is on E2E & live smoke.