Jens/MobilityOps
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

test: add targeted E2E coverage for branding, status flow, MO-016, and knowledge; fix two real bugs found along the way

Browse Source 
New frontend/e2e/fleet-ops-correction.spec.ts covers section 12 of the brief:
branding (Fleet Ops visible, no MobilityOps/PoC leaks, in all 3 languages), the
language switcher persisting across reload, the full status-recommendation flow
(non-mutating preview, exact-status confirm button, manual review with no apply
button, stale-token rejection), MO-016 order independence at the browser level, the
knowledge base grounding the exact brief question in its own language, and localized
audit/automation content with raw codes only under "Technical details".

Writing these tests surfaced two real bugs:

- DataQualityIssueDetail.tsx conflated "no conflict" with "manual review required"
  because both carry safe_to_apply: false (a no_conflict recommendation has nothing to
  apply, so it's trivially "not safe to apply" without being unsafe). This showed a
  false "manual review required" panel for MO-016 after its overlap was resolved,
  instead of the correct "no change needed" state. Fixed by keying the branch on
  manual_review_required alone.
- test_mo_016_status_conflict_recommendation_is_order_independent never actually
  exercised MO-016: _first_open() returned whichever vehicle_status_conflict issue was
  most recently detected (there are ~14 open after a reset), not necessarily
  DQ-DEMO-STATUS, so the test's MO-016 assertions were trivially true regardless of
  what the code under test did. Added _first_open_for_vehicle() and rewrote the test
  to explicitly target MO-016, and to assert the behaviour order independence actually
  requires: resolving the overlap first must correctly leave nothing to apply (the
  vehicle already matches the facts), not literally the same end status as resolving
  the conflict first.

151 backend tests, Ruff, mypy green; full 108-test Playwright suite green (two
transient, non-reproducible flakes confirmed to pass in isolation and unrelated to
this change).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
NuklearRabbit
2026-08-03 22:53:55 +02:00
co-authored by Claude Sonnet 5
parent ac4b1636fe
commit 1fdd2b3ccf
3 changed files with 346 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
frontend/src/pages/DataQualityIssueDetail.tsx
+9 -3
View File
@@ -553,11 +553,17 @@ function VehicleStatusConflictPanel({ issue, onResolved }: { issue: IssueDetail;
}
}
const needsManualReview =
recommendation !== null && (recommendation.manual_review_required || !recommendation.safe_to_apply);
// safe_to_apply is only ever true alongside a non-null recommended_status, so it must
// not be used to detect "manual review needed" -- a genuine no_conflict recommendation
// also carries safe_to_apply: false (there is nothing to apply), and conflating the two
// would show "manual review required" for a vehicle that needs no attention at all.
const needsManualReview = recommendation !== null && recommendation.manual_review_required;
const noChangeNeeded = recommendation !== null && !needsManualReview && recommendation.recommended_status === null;
const hasSafeRecommendation =
recommendation !== null && !needsManualReview && recommendation.recommended_status !== null;
recommendation !== null &&
!needsManualReview &&
recommendation.recommended_status !== null &&
recommendation.safe_to_apply;
return (
<section className="panel" aria-labelledby="status-conflict-heading">