medium priority medium complexity testing pending testing specialist Tier 9

Acceptance Criteria

Golden test: initial state on 375pt (iOS) — empty form, no error, submit disabled matches golden file
Golden test: initial state on 360dp (Android) — same conditions as above, separate golden file
Golden test: loading overlay on 375pt — spinner/overlay visible, form inputs visually disabled
Golden test: loading overlay on 360dp — same as above
Golden test: auth error banner on 375pt — ErrorBanner visible above form with mock error message
Golden test: auth error banner on 360dp — same as above
Golden test: VoiceOver focus outline on email field (375pt) — Semantics focus highlight visible on email input
Golden test: keyboard-raised layout on 375pt — form scrolls/adjusts to remain fully visible above keyboard
Golden test: keyboard-raised layout on 360dp — same as above
All goldens use a test organisation branding fixture (not production org data)
Golden files are committed to the repository under test/goldens/login_screen/
Running flutter test --update-goldens produces stable, deterministic output with no pixel noise
CI pipeline fails if goldens differ from committed files without --update-goldens flag

Technical Requirements

frameworks
Flutter
flutter_test
bloc_test
data models
LoginFormState (initial, loading, failure variants for golden fixtures)
OrganisationBranding (test fixture)
performance requirements
Each golden test completes within 5 seconds including rendering
Golden files are deterministic — no anti-aliasing variance between CI and local runs
security requirements
Golden fixtures must use synthetic/test organisation data — no real organisation names or credentials in committed test files
ui components
LoginScreen widget
MockLoginFormBLoC
Test organisation branding fixture
tester.binding.window.physicalSizeTestValue for screen size simulation
tester.binding.window.viewInsetsTestValue for keyboard simulation

Execution Context

Execution Tier
Tier 9

Tier 9 - 22 tasks

Can start after Tier 8 completes

Implementation Notes

Golden tests are the highest-maintenance test type — design them for stability first. Use RepaintBoundary around LoginScreen in the test harness to isolate rendering. Avoid any platform-specific fonts that differ between CI (Linux) and local (macOS/Windows) — use loadFontFromList in setUp to load the app's bundled fonts explicitly, otherwise text rendering will differ. For the loading overlay golden, ensure the mock BLoC state is LoginLoading before pumpAndSettle to avoid animation frame variance — use pump(Duration.zero) instead of pumpAndSettle for loading states with infinite animations (CircularProgressIndicator).

For the keyboard golden, combine physicalSizeTestValue with viewInsetsTestValue to simulate a realistic keyboard-raised viewport. Store all goldens under test/goldens/login_screen/ with descriptive filenames: login_screen_initial_ios.png, login_screen_error_android.png, etc. Document the golden update process in a comment at the top of the test file.

Testing Requirements

Golden tests in test/goldens/login_screen_golden_test.dart. Use flutter_test with matchesGoldenFile. Wrap LoginScreen in MaterialApp with the app's ThemeData and a test OrganisationBranding provider. For each state, seed MockLoginFormBLoC with the relevant state before pumping.

For keyboard-raised layout, set tester.binding.window.viewInsetsTestValue = WindowPadding(...) with a bottom value of 300dp to simulate keyboard. For VoiceOver focus golden, use tester.ensureSemantics() then SemanticsController.simulateFocus on the email field finder before screenshot. Run each golden on both screen sizes using physicalSizeTestValue. Add tearDownAll to restore window defaults.

CI must include --coverage and --reporter=json flags. Golden comparison threshold: exact pixel match (default Flutter golden tolerance).

Component
Login Screen
ui low
Epic Risks (3)
high impact medium prob scope

Automated accessibility checks (e.g., flutter_accessibility_service) may pass while manual VoiceOver/TalkBack testing reveals focus-order issues, missing semantic roles, or live region announcements that fire too early or not at all. Discovering these late risks delaying the MVP release.

Mitigation & Contingency

Mitigation: Conduct manual VoiceOver and TalkBack testing on physical devices at the end of every sprint, not only at release. Define accessibility acceptance criteria per component and include them in the DoD. Use Semantics widgets explicitly rather than relying on implicit semantics from Flutter's default widgets for all interactive elements.

Contingency: Maintain a prioritized accessibility bug backlog separate from the main backlog. If critical VoiceOver issues are found close to release, create an explicit accessibility hotfix sprint before TestFlight distribution to Blindeforbundet testers.

medium impact medium prob technical

Keyboard height varies significantly between iOS and Android, between device sizes (iPhone SE vs iPad), and with third-party keyboards. The KeyboardAwareLayout may not correctly adjust scroll offset in all combinations, causing input fields to remain hidden behind the keyboard on certain device/keyboard configurations.

Mitigation & Contingency

Mitigation: Test on a matrix of devices including iPhone SE (small viewport), a mid-size Android phone, and a tablet. Implement the layout using MediaQuery.viewInsets.bottom rather than a fixed padding value to correctly respond to any keyboard height. Include edge cases for floating keyboards on iPads.

Contingency: If device-specific issues are found after release, implement a bottom-padding fallback using BottomPadding inset and allow users to manually scroll. Log affected device/OS combinations for targeted fixes.

high impact low prob dependency

If the design token system's colour palette is updated without re-running contrast validation, form field labels, error messages, or placeholder text could fall below the WCAG 2.2 AA 4.5:1 ratio, causing a compliance regression.

Mitigation & Contingency

Mitigation: Integrate a contrast ratio validator (e.g., a CI lint step using the contrast-ratio-validator component) that checks all colour pairs used in the login form on every pull request. Document which token pairs are used for labels, errors, and backgrounds in the login form.

Contingency: If a contrast regression is detected post-merge, hot-patch the affected design token value. Do not ship a TestFlight build with known WCAG AA failures to Blindeforbundet testers.