🏠 Overview › ✅ Implementation Tasks ›✅ epic-coordinator-proxy-registration-core-task-011

Write integration tests for ProxyRegistrationService

epic-coordinator-proxy-registration-core-task-011 — Write integration tests using a Supabase local emulator for ProxyRegistrationService covering: full happy-path creation with valid dual attribution, validator rejection propagation (self-attribution, out-of-scope, duplicate), optimistic rollback on network failure, and correct domain event emission with all attribution fields populated.

high priority medium complexity testing pending testing specialist Tier 3

Acceptance Criteria

Happy-path test: calling submit() with valid dual-attribution data inserts exactly one row in proxy_activities with correct coordinator_id, mentor_id, activity_date, duration_minutes, and both attribution metadata fields populated
Self-attribution rejection test: submit() with coordinator_id == mentor_id returns AttributionValidationFailure.selfAttribution without writing to the database
Out-of-scope rejection test: submit() with a mentor not in the coordinator's assigned scope returns AttributionValidationFailure.outOfScope without writing
Duplicate rejection test: submit() for a record conflicting with an existing proxy_activity for the same mentor within the overlap window returns DuplicateWarning with conflicting_activity_id populated
Optimistic rollback test: when the Supabase insert succeeds but the subsequent domain event publish fails (simulated network error), the optimistic local state is rolled back and no success result is returned
Domain event test: successful submission emits a ProxyActivityCreatedEvent with all required fields (coordinator_id, mentor_id, activity_date, duration, attribution_metadata, timestamp)
All tests run against a Supabase local emulator (not production) and are isolated — each test seeds its own data and tears down afterwards
Test suite completes in under 60 seconds on CI

Technical Requirements

frameworks
Flutter
flutter_test
Supabase local emulator (supabase start)
apis
Supabase REST/PostgREST for proxy_activities table
ProxyRegistrationService internal API
ActivityAttributionValidator
data models
ProxyActivity
AttributionValidationResult
DuplicateWarning
ProxyActivityCreatedEvent
performance requirements
Full test suite must complete within 60 seconds to remain viable on CI
Each test must set up and tear down its own Supabase seed data to prevent inter-test pollution
security requirements
Tests must run with a test service-role key scoped to the local emulator only — never the production key
RLS policies must be active during integration tests to validate server-side enforcement

Execution Context

Execution Tier
Tier 3

Tier 3 - 413 tasks

Can start after Tier 2 completes

Implementation Notes

Spin up the Supabase local emulator in CI via 'supabase start' in a pre-test step (add to CI workflow yaml). For the optimistic rollback test, inject a fake event publisher that throws on publish and assert no committed row remains after the exception (requires the service to use a Supabase transaction or a compensating delete). Use a dedicated test Supabase project (local) with the full schema migration applied. Structure tests in a test/integration/ directory separate from unit tests.

For duplicate detection, insert a seed proxy_activity row for the same mentor with overlapping date/time before the test call. Ensure the test coordinator and mentor are seeded in the users table with appropriate roles before each relevant test.

Testing Requirements

Integration tests using flutter_test with the Supabase local emulator. Use setUp/tearDown to insert and clean fixture data. Each scenario must be a separate test() block with a descriptive name. Use expect() with typed matchers (isA(), etc.).

For the rollback test, use a Supabase client wrapper that throws after insert to simulate partial failure. Verify database state directly via Supabase client queries inside the test — do not rely solely on return values. All tests tagged 'integration' to allow selective CI execution.

Component
Proxy Registration Service
service medium
Dependencies (2)
Build ProxyRegistrationService that orchestrates the full single-proxy creation flow: (1) invoke ActivityAttributionValidator, (2) if valid, call proxy_activity_repository.create() with dual attribution, (3) emit typed domain events (ProxyActivityCreated) consumed by the BLoC layer, (4) return a ProxyRegistrationResult discriminated union covering success, validation failure, and network error cases. epic-coordinator-proxy-registration-core-task-008 Write exhaustive unit tests for ActivityAttributionValidator covering: self-attribution rejection, out-of-scope mentor rejection, duplicate window detection with boundary cases (exact same time, overlapping, adjacent non-duplicate), active/inactive mentor state handling, and happy-path pass-through. epic-coordinator-proxy-registration-core-task-003
Epic Risks (3)
medium impact medium prob technical

The 2-hour window duplicate detection logic requires querying existing proxy records with compound key matching (mentor + date + activity type within time range). If the query is too broad it produces false positives that frustrate coordinators; if too narrow it misses genuine duplicates that corrupt Bufdir data.

Mitigation & Contingency

Mitigation: Define the duplicate detection window as a configurable parameter from the start. Prototype the Supabase query with representative data covering edge cases (midnight boundaries, different activity types same day, same activity type different mentors) before finalising the implementation.

Contingency: If the detection produces excessive false positives in UAT, allow coordinators to explicitly acknowledge and bypass the duplicate warning with a reason field, preserving safety while reducing friction.

high impact medium prob scope

If the proxy registration form does not clearly distinguish between the acting coordinator and the attributed mentor, coordinators may submit records attributing activities to themselves, causing inaccurate Bufdir reporting and potential funding issues.

Mitigation & Contingency

Mitigation: Conduct UAT with at least one real coordinator via TestFlight before release. Use distinct visual treatment (different card colours, explicit 'Registering on behalf of:' label) and require the confirmation screen to show both identities prominently.

Contingency: Add a mandatory confirmation checkbox on the confirmation screen that explicitly names the attributed mentor, preventing accidental self-attribution from slipping through.

high impact medium prob security

Coordinators with multi-chapter access must select an active chapter context before the mentor list is filtered correctly. If chapter scope resolution fails or is bypassed, cross-org proxy registrations could occur, violating data isolation between chapters.

Mitigation & Contingency

Mitigation: Reuse the existing active-chapter-state and hierarchy-service components established by the org hierarchy feature. Add a guard that blocks entry to the proxy flow if no chapter context is active, prompting chapter selection first.

Contingency: If the chapter resolution service is unavailable, default to the most restrictive scope (no mentors visible) and surface a clear error message rather than showing an unfiltered mentor list.

Quick Links
All Tasks Execution Plan