End-to-end integration tests across all layers

epic-structured-post-session-report-screen-task-008 — Write end-to-end integration tests that exercise the full post-session report flow: open screen with a valid activity_id after session ends, detect existing draft and show indicator, fill all dynamic fields including way-forward items, submit the report, verify the record is persisted in Supabase with the correct activity_id and role-based RLS, and confirm the coordinator way-forward task is created. Use flutter_test with a Supabase test instance.

critical priority high complexity testing pending testing specialist Tier 4

Acceptance Criteria

Test suite: 'Open report screen with valid activity_id' — the screen renders the dynamic form without errors when navigated to with a valid activity_id belonging to the test peer mentor's assignment.

Test suite: 'Draft detection' — when a draft report exists for the activity_id in Supabase, the draft indicator banner is visible on screen open and all previously saved field values are pre-populated.

Test suite: 'Full form submission' — filling all dynamic fields and way-forward items and tapping submit results in: (a) a confirmation bottom sheet appearing, (b) the report record existing in Supabase with correct activity_id, peer_mentor_id, organization_id, and field values, (c) the coordinator way-forward task record being created in the tasks table with a reference to the report record.

Test suite: 'RLS isolation' — a test user from a different organization cannot read the submitted report record from Supabase even with a valid JWT (RLS blocks cross-tenant access).

Test suite: 'Submission failure recovery' — when Supabase is unavailable (simulated via mock), the error state is shown, the retry button re-triggers submission, and form data is not lost.

Test suite: 'Screen lock after submission' — attempting to re-open the report screen for an already-submitted activity_id shows the session-lock message and prevents re-submission.

All tests are idempotent — they clean up their test data after each run using Supabase service role key in tearDown.

Test suite runs in CI (GitHub Actions or equivalent) against the Supabase test instance without manual intervention.

Test execution time for the full suite is under 3 minutes.

Technical Requirements

frameworks

Flutter

flutter_test

BLoC

apis

Supabase PostgreSQL 15 — test instance

Supabase Auth — test user creation and JWT generation

Supabase Edge Functions — if coordinator task creation is Edge Function-triggered

data models

activity

activity_type

assignment

contact

performance requirements

Each integration test must complete within 30 seconds including Supabase round trips — use test-optimised Supabase client with minimal latency

Test data setup (seed) must complete in under 10 seconds — use batch inserts via Supabase service role client

security requirements

Supabase service role key for test teardown must be stored in CI secrets — never hardcoded in test files

Test users must be created in a dedicated test organisation with no overlap with production or staging data

RLS test must verify cross-tenant isolation using a separately authenticated test user JWT, not by disabling RLS

Test database must be reset between test runs to prevent state leakage across test cases

ui components

WidgetTester — Flutter's integration test driver for UI interaction

MockSupabaseClient — for failure simulation in unit/widget layers

Real SupabaseClient pointed at test instance — for integration layer tests

Execution Context

Execution Tier

Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

View Full Execution Plan

Implementation Notes

Structure tests in a dedicated integration_test/ directory, not the test/ directory, to leverage Flutter's integration test runner which supports real device/emulator execution. Use a TestSupabaseHelper class to encapsulate seed data creation and teardown — inject it into each test via setUpAll/tearDownAll. For the Supabase test instance, use a dedicated project created specifically for CI testing with Row Level Security enabled and identical policies to production — do not disable RLS in tests as this defeats the purpose of the RLS validation test cases. For simulating Supabase unavailability in failure recovery tests, use a MockSupabaseClient at the BLoC layer via dependency injection — do not attempt to take the test Supabase instance offline.

The coordinator way-forward task creation likely happens via a Supabase database trigger or Edge Function on report insert — verify the trigger is deployed to the test instance and include trigger deployment in the CI setup script. Use patrol or integration_test package for driving the Flutter UI in integration tests; avoid app_driver-style testing which is harder to maintain.

Testing Requirements

Use flutter_test's WidgetTester for UI interaction and a real Supabase test project (separate from staging/production) for data persistence tests. Test data setup: create test organisation, peer mentor user, coordinator user, contact, assignment, and activity via Supabase service role inserts in setUpAll. Each test case uses a unique activity_id to avoid inter-test interference. RLS isolation test uses supabase.auth.signIn with a different-organisation test user and verifies a .select() returns empty results.

Coordinator way-forward task creation test queries the tasks table after submission and asserts a record exists with the correct report_id and assignee coordinator_id. All tests run in CI via flutter test integration_test/ with SUPABASE_TEST_URL and SUPABASE_TEST_ANON_KEY environment variables. TearDown: delete all records created during the test using the service role client.

Component

Post-Session Report Screen

ui high

Dependencies (1)

After a successful report submission, display a confirmation screen or bottom sheet acknowledging the report was saved, then navigate back to the calling screen (activity detail or home). Include a 'Report submitted' live-region announcement for screen readers. If submission fails, surface a plain-language error with a retry option rather than a raw error code. epic-structured-post-session-report-screen-task-005

Epic Risks (2)

medium impact high prob technical

End-to-end integration tests that span Flutter UI → Supabase → RLS → storage are inherently flaky in CI due to network timing, test database state, and Supabase cold-start latency. Flaky tests erode confidence and slow the release pipeline.

Mitigation & Contingency

Mitigation: Use a dedicated Supabase test project with seeded org and user fixtures. Wrap all E2E tests in retry logic with a fixed seed and tear-down hooks. Keep E2E tests in a separate test suite that runs on-demand rather than on every PR, with unit and widget tests as the primary CI gate.

Contingency: If E2E tests remain unreliable, replace the Supabase calls in integration tests with a verified fake (in-memory repository implementations) and promote the real Supabase tests to a nightly scheduled run rather than blocking PR merges.

high impact medium prob security

Health status, course interest, and assistive device fields contain personal health data. If any logger, analytics event, or crash reporter captures field values — through automated error serialisation or developer-added debug logs — the feature could violate GDPR and Blindeforbundet's data processor agreement.

Mitigation & Contingency

Mitigation: Audit all log statements in the report feature's code paths before the epic is marked done. Apply a PII-safe logging wrapper that strips field values from any serialised form state before it reaches the logger. Add a CI lint rule that flags direct logger calls within report-related files.

Contingency: If PII is found in logs post-launch, immediately disable the affected logging call and rotate any credentials that were exposed. Notify the data protection officer and document the incident per GDPR Article 33 requirements.

Quick Links

All Tasks Execution Plan