Write widget tests for PasswordVisibilityToggle
epic-email-password-login-ui-task-013 — Write Flutter widget tests for PasswordVisibilityToggle: initial state obscures text, tapping toggle reveals text, tapping again re-obscures, semantic label updates between 'Show password' and 'Hide password', touch target size is at least 48x48 logical pixels (via tester.getSize). Include a golden test for both states against the design system dark background.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
PasswordVisibilityToggle should be designed as a self-contained stateful widget with an obscureText bool state and an optional onToggle callback — no BLoC dependency. This makes it trivially testable in isolation. The touch target enforcement should use SizedBox(width: 48, height: 48) or a minimum-size constraint around the IconButton — verify this in the widget implementation before writing the test. For golden tests, wrap in a Container with the design system's dark background colour (from design tokens, not hardcoded hex) to ensure golden stability across theme changes.
Use addTearDown(tester.binding.window.clearPhysicalSizeTestValue) after each screen-size golden test to avoid test pollution. Golden files must be regenerated and reviewed manually whenever the design tokens change.
Testing Requirements
Pure widget tests in test/widgets/password_visibility_toggle_test.dart. Pump PasswordVisibilityToggle inside a MaterialApp with the app's ThemeData for accurate golden rendering. For obscureText verification, pass a TextEditingController and assert the companion TextField's obscureText. For semantics, use tester.ensureSemantics() and find the Semantics node by type then assert its label property.
For size test, use tester.getSize(). Golden tests use matchesGoldenFile('goldens/password_toggle_obscured.png') and 'goldens/password_toggle_revealed.png'. Run goldens on two screen sizes by using tester.binding.window.physicalSizeTestValue. Commit golden files to repository under test/goldens/.
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.