Write widget tests for shared UI atoms
epic-peer-mentor-pause-management-foundation-task-013 — Write Flutter widget tests for ExpectedReturnDatePicker, CertificationExpiryWarningBanner, and PauseStatusIndicator. Cover rendering in all states, accessibility semantics correctness, callback invocation, design token color application, and edge cases such as null expiry dates and boundary date values.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Structure test files as: test/features/peer_mentor/widgets/expected_return_date_picker_test.dart, certification_expiry_warning_banner_test.dart, pause_status_indicator_test.dart. For CertificationExpiryWarningBanner null expiry test, ensure the widget implementation guards against null before computing days until expiry — the test will expose any unguarded null dereference. For date boundary tests, inject a clock abstraction (or use a testable 'now' parameter) so tests don't depend on the system clock — this prevents flakiness. For color token tests, avoid asserting against hardcoded hex values; instead resolve via Theme.of(context).appColors in both the widget and the test to keep tests resilient to token value changes.
Testing Requirements
All tests use flutter_test's WidgetTester. Wrap widgets in a MaterialApp with the app's ThemeData to correctly resolve design tokens. For date picker tests, use tester.tap + tester.pump sequence or provide a testable date-selection callback. For color token assertions, resolve the expected color from the theme in the test and compare against the rendered widget's decoration or icon color using tester.widget
For semantics tests, use tester.getSemantics(find.byType(WidgetType)) and assert label contains the expected string. Organize tests into three describe groups, one per widget. Aim for ≥95% line coverage across the three widget files.
Supabase RLS policies for coordinator-scoped status queries may be difficult to express correctly, especially for peer mentors assigned to multiple coordinators or chapters, leading to data leakage or overly restrictive access blocking valid queries.
Mitigation & Contingency
Mitigation: Design RLS policies using security-definer RPCs rather than table-level policies for complex multi-coordinator scenarios. Write a comprehensive RLS test matrix covering all role and assignment permutations before marking complete.
Contingency: Fall back to application-level filtering in the repository layer with explicit coordinator_id parameter checks if RLS proves intractable, and document the trade-off for security review.
The HLF Dynamics portal API contract may be undocumented or subject to change, causing the DynamicsPortalClient to break during development or production rollout.
Mitigation & Contingency
Mitigation: Obtain the full Dynamics portal API specification and credentials early in the sprint. Build the client behind a well-defined interface so the HLF-specific implementation can be swapped without affecting upstream services.
Contingency: If the Dynamics API is unavailable or unstable, stub the client with a feature-flag-guarded no-op implementation so all other epics can proceed to completion independently.
Supabase Edge Functions used as the nightly scheduler host may have cold-start latency or execution time limits that prevent reliable nightly certification checks on large mentor rosters.
Mitigation & Contingency
Mitigation: Benchmark Edge Function execution time against the expected roster size. Design the expiry check to process in paginated batches to stay within execution limits. Use pg_cron with a direct database function as an alternative trigger if Edge Functions prove unreliable.
Contingency: Migrate the scheduler trigger to pg_cron invoking a Postgres function directly, removing the Edge Function dependency entirely for the scheduling layer.