Write unit and integration tests for repository and service
epic-peer-mentor-pause-foundation-task-009 — Write Flutter unit tests for MentorStatusRepository covering all read/write paths with mocked Supabase client, and integration tests against a local Supabase instance verifying RLS policy enforcement. Write unit tests for CoordinatorNotificationService covering recipient resolution, push dispatch, and in-app dispatch with mocked FCM and notification repositories.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 6 - 158 tasks
Can start after Tier 5 completes
Implementation Notes
For mocking Supabase's fluent query builder chain (e.g., .from().select().eq().maybeSingle()), create a MockSupabaseQueryBuilder that returns preset responses. This pattern is reusable across all repository tests in the project — consider extracting to a test_helpers package if it does not already exist. Use mocktail's when(...).thenAnswer((_) async => ...) pattern consistently. For integration tests, use supabase_flutter's initialisation with a local URL and anon key from the docker-compose .env.
Seed the database with known fixture rows using the service-role key before each test and clean up with deleteAll after. For RLS tests, authenticate as a test coordinator user and verify that fetching another chapter's mentors returns an empty list (not an error, due to RLS SELECT policy). Document the docker-compose setup command in the test file header comment.
Testing Requirements
This task IS the testing task. Structure tests in three groups: (1) MentorStatusRepository unit tests — mock all Supabase calls using mocktail, test each public method independently. (2) MentorStatusRepository integration tests — spin up local Supabase with migration applied, insert fixture data, run real queries, verify RLS behaviour with two separate auth sessions. (3) CoordinatorNotificationService unit tests — mock IMentorStatusRepository, IFCMSender, and INotificationRepository interfaces, test all public methods and edge cases.
Run coverage with flutter test --coverage and verify lcov threshold. Tag integration tests with @Tags(['integration']) so they can be excluded from standard CI.
Supabase RLS policies for status reads and writes must correctly distinguish between a mentor editing their own status and a coordinator editing another mentor's status within the same chapter. Incorrect policies could allow cross-chapter data leakage or silently block legitimate status updates, causing hard-to-diagnose runtime failures.
Mitigation & Contingency
Mitigation: Write RLS policies with explicit role checks (auth.uid() = mentor_id OR chapter_coordinator_check()) and verify with integration tests that cover same-chapter coordinator access, cross-chapter denial, and self-access. Review policies with a second developer before merging.
Contingency: If policy errors surface after merge, temporarily widen policy to coordinator role globally while a targeted fix is authored; use Supabase audit logs to trace any unauthorised access during the interim.
CoordinatorNotificationService must correctly resolve which coordinator(s) are responsible for a given mentor's chapter. If the chapter-coordinator mapping is incomplete or a mentor belongs to multiple chapters (as with NHF multi-chapter memberships), the service could fail to notify or duplicate notifications to the wrong coordinators.
Mitigation & Contingency
Mitigation: Use the existing chapter membership data model and query all active coordinator roles for each of the mentor's chapters. Add a de-duplication step before dispatch. Write integration tests with fixtures covering single-chapter, multi-chapter, and no-coordinator edge cases.
Contingency: If resolution logic proves too complex at this stage, fall back to notifying all coordinators in the organisation until a proper chapter-scoped resolver can be delivered in a follow-up task.
Adding new columns to peer_mentors in production could conflict with existing application code that does SELECT * queries if new non-nullable columns without defaults are introduced, causing unexpected failures in unrelated screens.
Mitigation & Contingency
Mitigation: Make all new columns nullable or provide safe defaults. Use additive migration strategy with no column renames or drops. Run migration against a staging copy of production data before applying to live.
Contingency: Prepare a rollback migration script that drops only the new columns; coordinate with the team to deploy the rollback and hotfix immediately if production issues are detected.