Unit test OrgSelectionService selection lifecycle
epic-organization-selection-service-labels-task-009 — Write unit tests for OrgSelectionService covering: load organizations returns correct list, selectOrganization persists the choice, getSelectedOrganization restores persisted selection on cold start, clearSelection removes persisted data, and post-selection initialization triggers label provider refresh. Mock the OrgPersistenceRepository and Supabase client.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 6 - 158 tasks
Can start after Tier 5 completes
Implementation Notes
Instantiate OrgSelectionService inside ProviderContainer so Riverpod dependency injection mirrors production wiring. Stub OrgPersistenceRepository as an interface mock — do not use the concrete implementation. For the cold-start scenario, construct the service after setting up the persistence mock to return a stored id, then assert the service exposes the correct Organization on first access without an explicit selectOrganization() call. The post-selection label provider refresh assertion depends on how OrgSelectionService notifies OrgLabelsProvider; if via a Riverpod ref.invalidate() call, capture the ref using a spy ProviderContainer.
Keep fixture data in a separate test/fixtures/org_fixtures.dart file to share across test-009 and test-010.
Testing Requirements
Unit tests only using flutter_test. Use setUp() to construct a fresh service instance per test to prevent state leakage. Apply mockito/mocktail to stub OrgPersistenceRepository.load(), save(), and clear(), and the Supabase client list response. Use fakeAsync + pump() for any stream-based assertions.
Group tests into describe-style group() blocks: 'loadOrganizations', 'selectOrganization', 'getSelectedOrganization', 'clearSelection', 'post-selection side-effects'. Assert call counts with verify() to confirm no unexpected interactions. Aim for 100% branch coverage of OrgSelectionService public methods.
The OrgLabelsProvider must be fully initialized before any UI widget renders organization-specific text. If the service triggers label initialization asynchronously and the UI builds before the labels stream emits, widgets will briefly display raw label keys instead of human-readable text, which constitutes a WCAG 2.2 AA failure for screen readers that announce whatever text is present at render time.
Mitigation & Contingency
Mitigation: Design the OrgSelectionService.select() method to await OrgLabelsProvider initialization before completing its Future — callers receive a resolved future only after labels are ready. Use an AsyncValue loading state to gate UI rendering via Riverpod's when() pattern.
Contingency: If awaiting initialization causes perceivable UI lag, implement an optimistic render with a skeleton loading state that is announced by the live-region-announcer as 'Loading organization content' so screen readers do not announce raw keys.
If the label definitions loaded from the backend for each organization do not match the label key registry used in the UI, widgets will fall back to raw keys silently. This is particularly harmful for Blindeforbundet users relying on VoiceOver, where a raw key announced by a screen reader is incomprehensible.
Mitigation & Contingency
Mitigation: Define a compile-time label key registry (enum or const strings) and assert at OrgLabelsProvider initialization that all required keys are present in the loaded map. Log a structured warning for any missing key and substitute a human-readable fallback string rather than the raw key.
Contingency: If a label schema mismatch reaches production, the OrgLabelsProvider fallback mechanism ensures users see a reasonable English default rather than a raw key. A backend label patch can be deployed without an app release.