Define mock contact data models and test fixtures
epic-contact-list-management-ui-components-task-001 — Create Dart data classes and mock data fixtures for Contact and PeerMentor entities used as test inputs for all UI widgets in this epic. Include fields for name, role, organization label, notes preview, availability status, certification status, and assigned member count. These fixtures will be consumed by widget tests and Storybook-style preview scaffolds throughout the epic.
Acceptance Criteria
Technical Requirements
Implementation Notes
Place the file at test/fixtures/contact_fixtures.dart, not in lib/ — test fixtures are test-only code. Use const constructors where the model supports it (if using freezed or const-compatible models) for zero-cost instantiation. Mirror the field structure agreed in task-005 exactly — if that task changes the model schema, update fixtures accordingly. Consider organizing fixtures into a static class with named getters rather than top-level variables to avoid polluting the test namespace and make autocomplete cleaner.
The mockPeerMentorExpiredCert fixture is particularly important for validating certification warning UI in downstream widget tests.
Testing Requirements
No direct tests needed for the fixture file itself — correctness is validated by the widget tests that consume them. However, run a quick compile check (flutter analyze test/fixtures/) and ensure all fixtures are typed correctly (no dynamic).
Consider adding a single smoke test that asserts ContactFixtures.mockContactList.length > 0 to catch accidental emptying of the list.
Design token color values used in role badges, certification status indicators, and availability chips may not meet the WCAG 2.2 AA contrast ratio of 4.5:1 when rendered against card backgrounds, requiring rework after accessibility review and potentially blocking acceptance sign-off.
Mitigation & Contingency
Mitigation: Run the contrast-ratio-validator on every new token combination during widget development. Enforce the CI accessibility lint runner on all PRs touching visualization components, and validate against the contrast-safe-color-palette before finalizing card designs.
Contingency: If contrast failures are found late, adjust token values in the design token theme centrally — since all widgets consume design tokens rather than hardcoded colors, all affected widgets will be corrected by a single token update without per-widget changes.
The ContactViewSwitcher is required for Barnekreftforeningen but must not appear for other organizations. If the organization labels provider does not yet expose a reliable feature flag for this widget, it may render universally or be conditionally hidden in an inconsistent way, breaking the role-specific layout contract.
Mitigation & Contingency
Mitigation: Implement view switcher visibility as a constructor parameter on ContactListScreen injected from a provider, defaulting to hidden. Document the integration point for the org labels provider so the flag can be wired without changing the widget's API.
Contingency: If org labels integration is delayed beyond this epic, use a feature flag constant keyed to the Barnekreftforeningen organization ID as a temporary gate, with a tracked issue to replace it with the runtime labels provider before general release.