Unit tests for duplicate detection service
epic-proxy-activity-registration-core-services-task-008 — Write comprehensive unit tests for proxy-duplicate-detection-service covering: detection of a single conflict, detection of multiple conflicts for the same key, no-conflict path returns empty result, batch mode returns correct per-key conflict map, and voided records are excluded from conflict results. Use mocked repository layer to isolate service logic. Tests must cover both happy path and edge cases to guarantee correctness of the primary anti-double-counting guard.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Define a clear ActivityRepositoryInterface (abstract class) that proxy-duplicate-detection-service depends on so it can be mocked without real Supabase calls. Test data should use fixed UUID constants defined at the top of the test file for readability. For the voided exclusion test, ensure the repository mock returns a record with status='voided' and verify the service filters it out — this confirms the filtering logic is in the service layer, not assumed to be in the query. Use group() blocks to organise tests by scenario category (single, batch, edge cases).
Testing Requirements
Pure unit tests using flutter_test. Mock the ActivityRepository (or equivalent query interface) using Mockito or manual fakes. Test cases: (1) single conflict returned, (2) multiple conflicts same key, (3) empty result no match, (4) batch map with mixed results, (5) voided status excluded, (6) null/empty input to batch mode returns empty map without error. Use setUp() to initialize service with mock repository.
Verify mock.check() is called with the exact parameters passed to the service.
Overly strict duplicate matching (exact date + type) may flag legitimate back-to-back sessions of the same activity type on the same day as duplicates, frustrating coordinators and undermining trust in the feature.
Mitigation & Contingency
Mitigation: Confirm with product owners whether the matching key should be (mentor_id, date, activity_type_id) only or should also consider duration and time-of-day. Document the chosen threshold in the service and surface it in the duplicate warning dialog for transparency.
Contingency: If false-positive rates are high in user testing, add a duration-window tolerance parameter to the detection query that can be tuned without code changes.
If the current session token is invalidated between the coordinator starting the proxy form and submitting it, the activity-attribution-service may fail to resolve the coordinator's user ID, causing a silent attribution error.
Mitigation & Contingency
Mitigation: Read the coordinator's user ID from the session at service call time rather than at form-open time. Validate the session is still active before committing the insert, and surface a clear re-authentication prompt if it has expired.
Contingency: If a mis-attributed record is detected post-submission, the audit log retains the original session metadata, allowing a corrective record to be created with accurate attribution.