Integration test for full scheduler-to-card end-to-end flow
epic-scenario-based-follow-up-prompts-scheduler-and-ui-task-018 — Write an integration test that covers the complete flow: Scheduler Service runs against a seeded Supabase test instance, produces a prompt, which appears as a ScenarioPromptNotificationCard in the notifications tab, tapping opens the Detail Bottom Sheet with correct context, and the CTA deep link routes to the activity wizard screen.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 11 - 5 tasks
Can start after Tier 10 completes
Implementation Notes
Expose a testable hook on the Scheduler Service (e.g., a public runNow() method or a VisibleForTesting annotation) so the integration test can trigger it synchronously without waiting for a background timer. For Supabase seeding, create a TestDataSeeder helper class that encapsulates all insert/delete operations — this keeps the test body readable. Use meaningful test UUIDs (e.g., 'test-activity-e2e-001') prefixed consistently so teardown can use .delete().like('id', 'test-%') as a safety net. Ensure the test Supabase project has the same schema migrations as production — include a CI step that runs migrations against the test project before running integration tests.
For deep link routing, the activity wizard screen should be identifiable by a unique Key or route name — assert using find.byKey(Key('activity-wizard-step-1')) or find.byType(ActivityWizardScreen). If the scheduler runs on a background isolate in production, add a Flutter test mode that runs it on the main isolate to avoid isolate communication complexity in tests.
Testing Requirements
Use the Flutter integration_test package with IntegrationTestWidgetsFlutterBinding.ensureInitialized(). Structure: (1) setUp — authenticate test user against Supabase test project, insert seed rows via supabase.from('activities').insert(); (2) act — pump full app, trigger scheduler manually via exposed test hook or by navigating to notifications tab which triggers scheduler; (3) assert UI state step by step with pumpAndSettle between each interaction; (4) tearDown — delete all inserted rows by test-user ID. Run on a physical device or emulator via flutter test integration_test/ --dart-define=SUPABASE_TEST_URL=... --dart-define=SUPABASE_TEST_KEY=....
CI pipeline must set these env vars as secrets. Do not run against the production Supabase project.
If the scheduler runs concurrently (e.g., two overlapping cron invocations due to edge function retry), duplicate prompts could be dispatched before the first run's history records are committed, breaking the deduplication guarantee.
Mitigation & Contingency
Mitigation: Use a Postgres advisory lock or unique constraint on (user_id, scenario_id, activity_ref) in the prompt history table to make concurrent writes idempotent; design the scheduler to check history inside a transaction.
Contingency: If concurrency issues persist in production, add a distributed lock via Supabase Edge Function concurrency limit (max_instances=1) for the evaluation function as a hard guard.
Coordinators may find scenario configuration unclear if trigger conditions are expressed as raw JSON or technical terminology, leading to misconfiguration and irrelevant prompts being sent to peer mentors.
Mitigation & Contingency
Mitigation: Design the ScenarioConfigurationScreen to display human-readable descriptions of each template's trigger condition (e.g., 'Send 3 days after first contact if wellbeing concern was flagged') rather than raw rule properties; validate with an HLF coordinator in a design review before implementation.
Contingency: If coordinators still misconfigure rules after launch, add a preview mode that shows a simulated prompt based on a test activity before the rule is enabled.