Unit tests: ProxyDuplicateDetector coverage
epic-bulk-and-proxy-registration-services-task-013 — Write unit tests for ProxyDuplicateDetector covering: exact triple-key match returns warning with correct fields, partial match (same mentor + type, different date) returns no warning, bulk input with mixed matches returns only the affected mentors, empty candidate list returns empty result without hitting Supabase, and warning includes the original coordinator ID for cross-coordinator duplicate scenarios relevant to NHF chapters.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
The main testing challenge is the Supabase fluent query builder — it is difficult to mock at the client level. Two approaches: (1) wrap the Supabase query in a thin ActivityQueryPort interface (abstract class) and mock that — this is the cleanest approach; (2) use a fake Supabase in-memory implementation if one exists in the supabase_flutter test utilities. Approach (1) is strongly recommended for unit tests, with the real Supabase client wired in production and the integration tests (task-014) covering the real query behaviour. For the 'bulk input with mixed matches' test, construct MentorActivityCandidate fixtures with distinct UUIDs for each mentor and return a DuplicateQueryResult only for one of them from the mock — then assert the result list length is 1 and contains the correct mentorId.
Testing Requirements
Use flutter_test with mockito @GenerateMocks for the Supabase client. Because the Supabase Flutter client uses a fluent builder pattern (.from().select().in_().eq()), mocking it requires stubbing the entire builder chain or using a repository abstraction layer (preferred). If ProxyDuplicateDetector wraps the Supabase call in a private repository-like method, mock that method instead of the raw client. Use setUp() to build fresh test data (MentorActivityCandidate fixtures, DuplicateQueryResult fixtures) for each test group.
For freezed value objects, use == equality in expect() assertions. For the NHF multi-coordinator test, construct a DuplicateQueryResult with a different recorded_by_user_id than the calling coordinator and verify the field propagates to the warning output.
The Proxy Registration Service must verify that the coordinator has a legitimate assignment relationship with the target peer mentor before creating a record. If this check is implemented only in application code and not enforced at the DB/RLS level, a compromised or buggy client could bypass it by calling the Supabase endpoint directly, creating fraudulent proxy records for arbitrary peer mentors.
Mitigation & Contingency
Mitigation: Implement permission validation at two levels: (1) application-layer check in Proxy Registration Service that queries the assignments table before constructing the payload, and (2) RLS policy on the activities table that restricts INSERT to rows where recorded_by_user_id matches the authenticated user AND peer_mentor_id is in the set of peer mentors assigned to that coordinator. The RLS policy is the authoritative guard; the service-layer check provides early user-facing feedback.
Contingency: If RLS policy implementation is blocked by Supabase plan constraints, implement a Supabase Edge Function as a proxy endpoint that enforces the permission check server-side before forwarding to the DB. Disable direct client inserts entirely for proxy activities.
For a bulk session with 30 selected peer mentors, the Proxy Duplicate Detector must query existing activities for each mentor. If implemented as 30 sequential Supabase queries, round-trip latency could make the bulk confirmation screen feel slow (>3s), degrading coordinator experience and potentially causing timeouts.
Mitigation & Contingency
Mitigation: Implement the duplicate check as a single Supabase query using an IN clause on peer_mentor_id combined with the activity_type and date filters, returning all potential duplicates for the entire batch in one network round-trip. Group results client-side by mentor ID to produce the per-mentor warning structure.
Contingency: If the single-query approach returns too much data for very large chapters, add a database index on (peer_mentor_id, activity_type, date) and profile query time. If still insufficient, accept a short loading state on the confirmation screen with a progress indicator rather than pre-loading duplicates before navigation.