Integration test full data layer end-to-end
epic-activity-type-configuration-foundation-task-014 — Write integration tests that exercise the complete stack from Supabase client through repository, cache provider, and metadata resolver. Verify that RLS policies correctly block cross-org reads, that the cache is populated on first access and served from memory on subsequent reads, and that cache invalidation propagates correctly after a write. Use a dedicated Supabase test project or local emulator.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 6 - 158 tasks
Can start after Tier 5 completes
Implementation Notes
The most complex aspect is authenticating as two different test users within the same test suite to verify RLS. Use Supabase's Admin Auth API to create test users server-side in setUpAll(), obtain JWTs for each, then construct separate SupabaseClient instances with each JWT injected as the auth token — do not use the singleton supabase.auth.signIn() as it mutates global state. For the cache verification test (second read hits no DB), instrument the repository with a call counter (thin wrapper or spy pattern) rather than relying on network inspection. For CI integration, add a GitHub Actions job that runs supabase start, waits for health check, runs flutter test --tags integration, then runs supabase stop.
Store test credentials in GitHub Secrets. Never run integration tests against production — add a guard assertion in setUpAll() that checks the Supabase URL contains 'test' or 'local'.
Testing Requirements
flutter_test integration tests using real Supabase connections. Structure: setUpAll() provisions two test organisations (org_a, org_b) and two test users with distinct org claims via Supabase Auth Admin API; setUp() seeds known activity types for each org; tearDown() deletes seeded records; tearDownAll() deletes test users and orgs. Test groups: group('RLS isolation', ...) — cross-org reads return no data; group('cache population', ...) — first access hits DB, subsequent reads do not; group('cache invalidation', ...) — write operations trigger re-fetch; group('resolver integration', ...) — cached items have correct resolved metadata. Use ProviderContainer with overrides to inject org-scoped auth for each test.
Run with: flutter test integration_test/activity_type_data_layer_test.dart --tags integration.
The JSONB metadata column has no enforced schema at the database level. If the Dart model and the stored JSON diverge (e.g., a field is renamed or a new required flag is added without a migration), the metadata resolver will silently return null or throw at parse time, breaking conditional wizard logic for all organisations.
Mitigation & Contingency
Mitigation: Define a versioned Dart Freezed model for ActivityTypeMetadata and add a Supabase check constraint or trigger that validates the JSONB structure on write. Document the canonical metadata schema in a shared constants file and require schema review for any metadata field additions.
Contingency: Implement a lenient parse path in ActivityTypeMetadataResolver that returns safe defaults for missing fields and logs a structured warning to Supabase edge logs, allowing the app to degrade gracefully rather than crash.
If RLS policies on the activity_types table are misconfigured, a coordinator from one organisation could read or mutate activity types belonging to another organisation, violating data isolation guarantees required by all three client organisations.
Mitigation & Contingency
Mitigation: Write integration tests against the Supabase local emulator that explicitly assert cross-org isolation: a token scoped to org A must receive zero rows when querying org B activity types, and upsert attempts must return permission-denied errors.
Contingency: Apply an emergency RLS policy patch via Supabase dashboard without a code deploy. Audit all activity_type rows for cross-org contamination and restore from backup if any data leakage is confirmed.
If the cache invalidation call in ActivityTypeService is not reliably triggered after an admin creates, edits, or archives an activity type, peer mentors on the same device will see stale data in the registration wizard until the next app restart, leading to confusion and potential misregistrations.
Mitigation & Contingency
Mitigation: Enforce a strict pattern: ActivityTypeService always calls cacheProvider.invalidate() inside the same try block as the successful Supabase mutation, before returning to the caller. Write a widget test that verifies the cache notifier emits an updated list after a service mutation.
Contingency: Add a background Supabase Realtime subscription on the activity_types table that triggers cache invalidation automatically, providing an independent safety net independent of the service call path.