End-to-end test for single proxy registration journey
epic-coordinator-proxy-registration-core-task-014 — Write an integration_test (Flutter driver) end-to-end test that simulates the complete coordinator journey: open ProxyRegistrationScreen, select a mentor via the single-select widget, optionally apply a recurring template, fill remaining fields, submit, observe the confirmation screen, and verify the proxy_activities row exists in Supabase with correct coordinator_id, mentor_id, and dual attribution metadata.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 8 - 48 tasks
Can start after Tier 7 completes
Implementation Notes
Place E2E tests in integration_test/ directory (not test/) as required by the Flutter integration_test package. Use a shared E2ETestHelpers class for: Supabase seed/teardown methods, common finders, and auth setup. For mentor selection, the single-select widget likely renders a search TextField followed by a list — use tester.enterText() on the search field, pumpAndSettle(), then tap the matching ListTile. Do not hardcode mentor display names — derive them from the seed fixture.
For the optional template path, check a feature flag constant and conditionally include the template steps. Ensure the app's Supabase client is pointed at the local emulator URL (http://127.0.0.1:54321) during E2E runs via a --dart-define or test environment variable. The confirmation screen assertion (find.byType) combined with a direct Supabase query provides dual verification — UI success alone is insufficient given the dual attribution requirement.
Testing Requirements
Use the Flutter integration_test package with IntegrationTestWidgetsFlutterBinding.ensureInitialized(). Seed all required database fixtures (coordinator, mentor, optional template) in setUpAll using the Supabase service-role client. Use find.byType() and find.text() with finite timeouts (default pumpAndSettle timeout 100 frames is often insufficient — set explicit Duration). After confirmation screen appears, use the Supabase service-role client inside the test to query proxy_activities and run expect() assertions on the returned row.
Run tearDownAll to delete all seeded rows and auth users. Tag with @Tags(['e2e']) to allow selective CI execution. Target TestFlight (iOS) as the primary E2E validation platform per the workshop agreement with all three organisations.
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.
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.
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.