Manual Test Plans — Projection Visualization & Actions
Operator-facing test plans for the projection / subscription surface in CritterWatch's BFF UI. Tracks CritterWatch#314.
Each plan is a sequence of test steps in the format the issue prescribed:
| Field | What it captures |
|---|---|
| Setup | Which sample family, scale, launch profile (Aspire scenario, env vars, CLI flags) |
| Action | The operator interaction or external event under test |
| Expected observation | What the UI should render — or what alert should fire |
| How to verify | Concrete handles — UI element under what selector, capability snapshot field, mt_event_progression columns to query directly |
Scenario families
| Plan | Substrate | Notes |
|---|---|---|
| Viewing | Trip / TeleHealth / MultiStoreHost | Projections list + detail pages; per-store HWM; shard-state badges; dead-letter section policy awareness |
| Actions | Trip family | Pause, restart, rebuild, rewind across single-store async projections |
| Long-running rebuilds (priority) | TeleHealth (5 tenants × 50k events default; 50 × 400k upstream max) | Rebuild duration, mid-flight pause/restart, process kill + recovery, force-apply-error, cluster failover |
| Multi-store | MultiStoreHost (MainPlusAncillary + AncillaryOnly modes) | All actions against ancillary projections; per-store HWM independence |
| Multi-tenancy | MTTrips (master-table dynamic tenancy); TeleHealth (conjoined + hash-partitioning) | Dynamic tenant add / disable / enable; per-tenant ops |
The long-running rebuilds plan is the priority area; everything else is round-out. Read the priority plan first if you only have time for one.
Substrate quick-reference
Set up the right Aspire scenario before running any plan below.
| Sample | What it gives you | Aspire profile |
|---|---|---|
Trips (RepairShop + TripService + TripPublisher) | Standard 3-projection async setup over RabbitMQ + Marten | Full (default) |
Trips2 | Repeat of Trips with a separate prefix; useful for "two services side by side" tests | Full |
Trips3 | Trip family over Amazon SQS via LocalStack + brotli compression | Full |
PolecatTrips | Trip family backed by Polecat instead of Marten | Full |
MTTrips | Trip messaging over LocalStack SQS + Marten master-table dynamic tenancy | Full, or tenancy for dedicated profile |
Incidents | Stop-on-error projection sample (PS#3 substrate) | Full |
TeleHealth | Marten.ScaleTesting-derived; default 5 tenants × 50k events, scalable via CLI flags | Full (default scale), or multi-store for AncillaryOnly |
MultiStoreHost | Three Marten stores (Trips + Incidents + TeleHealth) in one process — PS#2 substrate | Full or multi-store |
ModularMonolith | Four-module sample with local-queue inter-module messaging | Full |
Aspire scenarios are selected via the CRITTERWATCH_SCENARIO env var on BffHost, or via launch profile in Properties/launchSettings.json. See src/BffHost/README.md for the full mode matrix.
Verification handles
Every plan ends each step with a "How to verify" line. The common handles, in order of preference:
- UI element with a
data-testid— preferred when one exists (the Vue components added them defensively in #314, #150, #309 follow-ups). Cite the testid directly so the verification is automatable later. - UI element with a stable text + selector pair — e.g.
el-card:has-text("…"),el-table__row[data-row-key="…"]. Cite the pair. - BFF API or SignalR snapshot —
GET /api/critterwatch/service-summaries/<service-id>returns the sameServiceSummaryaggregate the UI renders from. Curl it when the UI's render is in doubt. - Raw Marten / Polecat tables —
mt_event_progression(Marten) orpc_event_progression(Polecat). Use these when the test exercises low-level daemon behaviour (HWM, agent_status, pause_reason, running_on_node, warning/critical_behind_threshold per the 6-column extended-progression-tracking surface).
When a plan asks for a "How to verify" step that requires raw-table access, the SQL is included inline so the operator doesn't need to context-switch.
Cross-references
- #309 — Long-running projection rebuild orchestration (design partner for the rebuild plan; cross-referenced where tests depend on unimplemented features).
- PS#2 — issue #2 — multi-store HWM rendering (fix landed in #329 / #333 / #334 / #335).
- PS#3 — issue #3 — projection error-policy aware DLQ section (fix landed in #326 / #327 / #328).