Integration test: selection screen end-to-end with cache
epic-activity-type-configuration-business-logic-task-010 — Write an integration test that boots the Riverpod provider graph with a real ActivityTypeCacheProvider backed by a mocked Supabase client. Verify that the ActivityTypeSelectionScreen fetches from the cache on second load without a network call, that cache invalidation after a service mutation causes the next read to refetch, and that the selected ActivityType metadata (triggersReimbursementWorkflow, isTravelExpenseEligible) is correctly propagated back to the registration wizard orchestrator.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 8 - 48 tasks
Can start after Tier 7 completes
Implementation Notes
Mock the Supabase client at the SupabaseClient constructor level by overriding the supabaseClientProvider in ProviderScope. Return pre-built List
For mutation-then-refetch, call the service mutation on the ProviderContainer, then rebuild the selection screen widget and verify the mock was called a second time. For wizard propagation, wrap ActivityTypeSelectionScreen inside a minimal RegistrationWizardOrchestrator stub that reads the selected ActivityType from shared Riverpod state and conditionally renders downstream steps.
Testing Requirements
Flutter integration tests using flutter_test with testWidgets(). Use a real ProviderContainer or ProviderScope booting the full production provider graph, overriding only the Supabase client with a mocktail Mock. Count Supabase mock invocations using verify().called(n). For wizard propagation tests, navigate the full wizard flow using tester.tap() and tester.pumpAndSettle().
Assert presence/absence of downstream wizard widgets using find.byType(). Tests must be runnable with flutter test — no dependency on a running device or emulator beyond what flutter_test provides.
Metadata flag combination rules differ between organisations (e.g., Blindeforbundet honorarium thresholds, HLF mutual exclusion of km and transit). Encoding these as generic service-level validation may be insufficient, forcing organisation-specific branching inside the service that becomes unmaintainable as new organisations are onboarded.
Mitigation & Contingency
Mitigation: Model flag validation as a pure function that accepts an ActivityTypeMetadata object and an org configuration record, making org-specific rules data-driven rather than hardcoded. Establish the validation contract in the foundation epic so the service just delegates to the validator.
Contingency: Defer complex cross-flag validation to a lightweight edge function that can be updated without a mobile app release, accepting that initial validation in the mobile service layer is permissive and corrected server-side.
Blindeforbundet users rely on VoiceOver and JAWS. If the selection screen is built with non-semantic widgets that fail accessibility audit late in the sprint, a significant rework of the widget tree may be required, blocking the registration wizard integration.
Mitigation & Contingency
Mitigation: Build the selection screen against the project's established accessibility design tokens and semantics wrapper conventions from the start. Run Flutter's semantic tree inspector and a manual VoiceOver pass before marking any widget task complete.
Contingency: Wrap all tappable items in the project's SemanticsWrapperWidget and schedule a dedicated accessibility review session with a screen reader user from Blindeforbundet before the epic is closed.