Write unit and integration tests for repository layer
epic-peer-mentor-pause-management-foundation-task-012 — Write unit tests for PeerMentorStatusRepository and CertificationStatusRepository covering CRUD operations, RPC call contracts, error handling, and realtime subscription behavior. Write integration tests against a local Supabase instance to validate RLS policies block unauthorized access and RPC functions perform correct atomic transitions.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Abstract the Supabase client behind a SupabaseClientProvider interface to enable injection in tests. Use mocktail rather than mockito to avoid code generation overhead. For realtime subscription tests, inject a fake RealtimeChannel that you can manually trigger with test payloads — do not rely on timing. For integration tests, use a separate supabase project config (config.test.toml) pointing to localhost:54321.
Seed data with SQL fixtures applied via supabase db reset --local. Ensure each integration test cleans up after itself (DELETE WHERE id IN test_ids) to remain idempotent. Pay special attention to the pause RPC atomicity test: wrap the call in a begin/rollback block to verify both status and timestamp are set before commit, and neither is set if an error occurs mid-transaction.
Testing Requirements
Unit tests: use mocktail to mock SupabaseClient, SupabaseQueryBuilder, and RealtimeChannel. Test each repository method in isolation. For streams, use StreamController in tests. Integration tests: spin up local Supabase via supabase CLI (supabase start), apply migrations, seed with fixture data covering: a coordinator user, two mentor users (one in active state, one in paused state), and expired certification records.
Run integration tests as a separate test target (flutter test integration_test/repository/). Verify RLS, RPC atomicity, and realtime event delivery end-to-end.
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.