Write golden tests for LoginScreen UI states
epic-email-password-login-ui-task-014 — Write golden tests for LoginScreen covering five states: initial (empty form), loading overlay, auth error banner, VoiceOver focus outline visible on email field, and keyboard-raised layout. Use matchesGoldenFile with a test organisation branding fixture. Run goldens on both iOS (375pt) and Android (360dp) logical sizes to catch layout regressions across platforms.
Acceptance Criteria
Technical Requirements
Execution Context
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).
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.
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.
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.