🏠 Overview › ✅ Implementation Tasks ›✅ epic-expense-approval-workflow-foundation-task-016

Widget test ClaimStatusBadge rendering and accessibility

epic-expense-approval-workflow-foundation-task-016 — Write widget tests for ClaimStatusBadge verifying: correct colour rendered for each ClaimStatus enum value, correct semantics label set for each status (for VoiceOver/TalkBack), badge renders at default and custom sizes without overflow, and badge is visually distinct (contrast ratio meets WCAG 2.2 AA) for all status variants.

medium priority low complexity testing pending testing specialist Tier 4

Acceptance Criteria

For every ClaimStatus enum value (pending, approved, rejected, under_review, auto_approved), a test case exists verifying the rendered badge background and text colours
Semantics node for each badge has a non-empty label property matching the human-readable English status string (e.g., 'Approved', 'Pending review')
Badge rendered at default size (no explicit size set) does not overflow its parent in a 320px wide viewport
Badge rendered with custom size prop (e.g., BadgeSize.large) scales without overflow in a 320px wide viewport
Text-to-background contrast ratio is >= 4.5:1 for all status variants, computed in test via a helper and compared against WCAG 2.2 AA threshold
No RenderFlex overflow errors or exceptions thrown during any widget test
Tests are parameterised over all ClaimStatus values so adding a new status value automatically fails the test until colour and label are configured

Technical Requirements

frameworks
flutter_test
data models
ClaimStatus
performance requirements
All widget tests pump and settle within 1 second per variant
ui components
ClaimStatusBadge
Semantics

Execution Context

Execution Tier
Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

Implementation Notes

ClaimStatusBadge must look up colours from the design token system (not hardcoded hex values) — this ensures consistency with the overall dark-mode design system described in the architecture. Status-to-colour mapping should live in a ClaimStatusBadgeTheme extension on ThemeData so tests can override it in isolation. For accessibility: the Semantics widget wrapping the badge must set `label` to the localised status string and `excludeSemantics: true` on child text to avoid double-reading. HLF's users include people with hearing impairments who rely on screen reader support — WCAG 2.2 AA contrast is non-negotiable.

The contrast helper can use Flutter's Color.computeLuminance() API directly.

Testing Requirements

Widget tests using flutter_test's WidgetTester. Wrap badge in a MaterialApp with the project's design token theme. Use tester.getSemantics(find.byType(ClaimStatusBadge)) to assert semantics label. Use tester.takeException() after each pumpAndSettle() to assert no overflow errors.

For contrast ratio: extract foreground and background Color from the rendered widget's decoration/text style; implement a helper `double contrastRatio(Color fg, Color bg)` using WCAG relative luminance formula; assert result >= 4.5. Parameterise with ClaimStatus.values.forEach to guarantee full enum coverage. No golden file tests — colour assertions must be logic-based to be CI-stable across platforms.

Component
Claim Status Badge
ui low
Dependencies (1)
Implement the ClaimStatusBadge Flutter widget that renders a colour-coded pill/chip for each claim status (draft=grey, submitted=blue, pending_approval=amber, approved=green, rejected=red, exported=purple). Accept a ClaimStatus enum value and optional size parameter. Ensure full semantics label for screen reader accessibility. Export from a shared widgets barrel file. epic-expense-approval-workflow-foundation-task-010
Epic Risks (3)
medium impact medium prob technical

Optimistic locking in ExpenseClaimStatusRepository may produce excessive concurrency exceptions in high-volume coordinator sessions where multiple coordinators process the same queue simultaneously, causing confusing UI errors and coordinator frustration.

Mitigation & Contingency

Mitigation: Design the locking strategy with a short retry window (1-2 automatic retries with 200ms back-off) before surfacing the error to the UI. Document the concurrency model clearly so the UI layer can display a contextual 'claim was already actioned' message rather than a generic error.

Contingency: If contention remains high under load testing, switch to a last-writer-wins update with a conflict notification rather than a hard block, and log all concurrent edits for audit purposes.

medium impact medium prob integration

FCM device tokens stored for peer mentors may be stale (app reinstalled, token rotated) causing push notifications for claim status changes to silently fail, leaving submitters unaware their claim was approved or rejected.

Mitigation & Contingency

Mitigation: Implement token refresh on every app launch and store updated tokens in Supabase. ApprovalNotificationService should fall back to in-app Realtime delivery when FCM returns an invalid-token error and should queue a token refresh request.

Contingency: If FCM delivery rates fall below acceptable thresholds in production monitoring, add a polling fallback in the peer mentor claim list screen that checks status on foreground resume.

high impact low prob dependency

Supabase Realtime has per-project channel and connection limits. If many coordinators and peer mentors are simultaneously subscribed across multiple screens, the project may hit quota limits causing subscription failures.

Mitigation & Contingency

Mitigation: Design RealtimeApprovalSubscription to use a single shared channel per user session rather than per-screen subscriptions. Implement subscription reference counting so channels are only opened once and reused across screens.

Contingency: Upgrade the Supabase plan tier if limits are reached, and implement graceful degradation to polling with a 30-second interval when Realtime is unavailable.

Quick Links
All Tasks Execution Plan