Unit tests for CertificationRecordRepository and MentorActivityLogRepository
epic-peer-mentor-detail-screen-data-layer-task-011 — Write unit tests for CertificationRecordRepository and MentorActivityLogRepository using mocked Supabase clients. CertificationRecordRepository tests must explicitly verify null return for NHF/Blindeforbundet org IDs and non-null return for HLF org IDs. MentorActivityLogRepository tests must cover all four ActivityPeriod enum values, empty result handling, and pagination cursor behavior for raw log queries.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Reuse the MockSupabaseBuilder test helper from task-010 if it was created. For the ActivityPeriod enum coverage, use a parameterized test pattern (Dart does not have @ParameterizedTest, but a helper loop or a list of test cases with forEach works well). The critical thing to verify for ActivityPeriod.allTime is that no date filter parameters are sent — use verifyNever on the .gte() call on the mock builder. Keep CertificationRecord tests focused: the org-branching logic is the most important invariant to protect, since incorrect behavior here would either expose HLF data to wrong orgs or hide data from HLF users.
Testing Requirements
Two separate test files. Use mockito/mocktail with fresh mock instances per test via setUp(). For ActivityPeriod tests, inject a Clock or fixed DateTime into the repository so date range calculations are deterministic — use a helper that returns a fixed 'now' value. For cursor pagination tests, provide mock data equal to the limit count and assert nextCursor is non-null; provide mock data with fewer than limit records and assert nextCursor is null.
Use verifyNever(mockSupabase.from(any)) for the NHF/Blindeforbundet short-circuit tests to guarantee zero queries. All test descriptions in English using given/when/then style.
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.