Unit tests for PeerMentorRepository
epic-peer-mentor-detail-screen-data-layer-task-010 — Write unit tests for all PeerMentorRepository methods using mocked Supabase client. Tests must cover: successful profile fetch, mentor not found exception, status update with and without return date, org-filtered list with active/paused/null status filter, and empty org result. Use flutter_test and mockito. Ensure RLS policy enforcement is trusted at the Supabase layer and not re-tested in unit tests.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Mocking the Supabase Flutter client's fluent builder chain (from(), select(), eq(), single(), execute()) requires either a custom fake or mocktail's when().thenAnswer() chaining. Consider creating a shared MockSupabaseBuilder helper in test/helpers/ that other repository test files can reuse — this avoids duplicating the mock chain setup across the three test files in this epic. Do not use @visibleForTesting to expose internal repository state for testing; test only through the public interface. If the repository depends on a SupabaseClient injected via constructor, ensure tests inject the mock via the constructor — do not rely on a global singleton.
Testing Requirements
Pure unit tests using flutter_test. Use mockito's @GenerateMocks or mocktail's registerFallbackValue pattern to mock the Supabase client and PostgREST builder chain. Each test uses setUp() to create a fresh mock instance. Verify mock interactions with verify()/verifyNever() where the absence of a call is the assertion (e.g., no status filter when null is passed).
Use throwsA(isA
Supabase RLS policies for peer mentor data may block coordinator queries if the RLS rules are written for peer-mentor-self access only, requiring policy updates that affect other features sharing the same tables.
Mitigation & Contingency
Mitigation: Review existing RLS policies on peer_mentors, certification_records, and activity_log tables before writing repository queries. Coordinate with the database team to add coordinator-role predicates without weakening existing mentor-self policies.
Contingency: If policy changes are blocked, implement a Supabase Edge Function as a secure query proxy that enforces authorization server-side, avoiding direct RLS policy modification.
The activity log table schema may not have a mentor_id foreign key column or may require a JOIN through an intermediate table, making the aggregation query significantly more complex than anticipated.
Mitigation & Contingency
Mitigation: Inspect the actual Supabase activity_log table schema before starting the MentorActivityLogRepository implementation. Document the exact JOIN path needed and validate it returns correct results for a known mentor.
Contingency: If schema requires complex multi-table aggregation, implement a Supabase database function (RPC) and expose it via the repository's fetchSummary method to keep Dart code clean.
The Blindeforbundet assignment table may not yet exist in the shared Supabase schema or may have a different structure than assumed, blocking the AssignmentHistoryRepository implementation.
Mitigation & Contingency
Mitigation: Verify the assignments table exists and confirm its column structure with the Contact Detail & Edit Screen team which also depends on assignment data (assignment-repository in that feature).
Contingency: If the assignments table is not yet available, implement the AssignmentHistoryRepository with a stub returning empty list and a TODO marker, unblocking the aggregation service while the schema is finalized.