high priority medium complexity testing pending testing specialist Tier 4

Acceptance Criteria

Test file compiles and all tests pass with `flutter test` with no skipped tests
Test: initial state — CircularProgressIndicator is visible, report sections are not
Test: loaded state with no warnings — validation banner is absent, all report sections render in the expected order
Test: loaded state with validation warnings — BufdirValidationBanner is visible and displays the correct warning count
Test: export button tap with warnings present — ConfirmationDialog appears with correct message
Test: export button tap with no warnings — no dialog appears, navigation event is triggered
Test: navigation on export confirm — GoRouter/Navigator receives correct route with session state payload
Test: navigation on export cancel — screen remains on preview, no navigation occurs
All mocks are defined using Riverpod provider overrides — no Mockito-generated mocks unless already used in the codebase
Tests are isolated: each test sets up its own mock state and does not depend on execution order

Technical Requirements

frameworks
Flutter
flutter_test
Riverpod (ProviderScope overrides)
apis
BufdirPreviewService (mock)
BufdirFieldValidationService (mock)
data models
BufdirPreviewState
BufdirValidationResult
BufdirReportSession
performance requirements
All widget tests must complete within 30 seconds total on CI
security requirements
Test fixture data must not contain real personal data — use generated dummy values only
ui components
BufdirPreviewScreen
BufdirValidationBanner
ConfirmationDialog
Export button (identified by key or semantics label)

Execution Context

Execution Tier
Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

Implementation Notes

Use `ProviderScope(overrides: [...])` to inject mock services rather than constructor injection, keeping tests consistent with the production Riverpod architecture. Create a helper `pumpBufdirPreviewScreen(WidgetTester tester, {required BufdirPreviewState initialState, required BufdirValidationResult validationResult})` to reduce boilerplate across tests. For navigation assertions, use a `GoRouter` test observer or check that a specific route name was pushed. For dialog assertions, use `find.byType(ConfirmationDialog)` and `expect(..., findsOneWidget)`.

Ensure the test for 'navigation passes correct session state' actually inspects the route arguments — do not just assert navigation occurred.

Testing Requirements

This task IS the testing work. Each test case must follow the Arrange-Act-Assert pattern. Wrap the widget under test in ProviderScope with explicit overrides for BufdirPreviewService and BufdirFieldValidationService. Use `tester.pumpAndSettle()` after state transitions.

Use widget keys or semantics finders (not text finders) for locating interactive elements to avoid brittle tests. Fixture data should be defined as shared constants at the top of the test file. Add a group label per scenario for readable test output. Target: 7 test cases minimum matching the acceptance criteria above.

Component
Bufdir Report Preview Screen
ui high
Epic Risks (3)
medium impact medium prob integration

The preview screen must pass period, scope, and aggregation session state to the Bufdir Report Export screen via navigation arguments. If the export screen's navigation argument schema is not yet finalized when this epic begins, the handoff will require rework — potentially after TestFlight is already in use by coordinators.

Mitigation & Contingency

Mitigation: Define the shared BufdirExportNavigationArgs Dart class jointly with the Bufdir Report Export feature team before this epic starts. Store it in a shared models package both features depend on. Treat the class as an API contract with a minor-version bump policy.

Contingency: If the export screen's argument schema changes after the preview screen is implemented, the BufdirPreviewService session state model can be adapted with a compatibility shim. The preview screen itself requires only a one-line navigation call change.

medium impact low prob technical

The period diff view loads prior-period data on demand and renders it inline with the current report. On a large report (many sections, many fields) combined with slow Supabase connectivity, the diff overlay could block the UI or produce a janky re-render that degrades the coordinator experience during the pre-submission review.

Mitigation & Contingency

Mitigation: Load prior-period data in a background Riverpod FutureProvider that starts prefetching when the preview screen mounts (not when the user taps the diff toggle). Show a shimmer placeholder on each field row's prior-period column while loading. Cache prior-period data in BufdirPreviewRepository using the same local cache as current-period data.

Contingency: If diff view performance is unacceptable on TestFlight devices, disable the toggle for the initial TestFlight release and ship the diff view in the following sprint after profiling the Supabase query plan and adding an appropriate Postgres index on the prior-period data table.

high impact medium prob scope

The full preview screen will be reviewed by coordinators on TestFlight who will cross-reference it against their physical Bufdir reporting forms. Any section ordering difference or label mismatch discovered during UAT will require a fix before the feature can be signed off, potentially delaying the entire Bufdir reporting pipeline.

Mitigation & Contingency

Mitigation: Conduct a pre-TestFlight alignment review with at least one coordinator from NHF and one from HLF using a static screenshot of the preview screen layout. Obtain written sign-off on section order and field labels before distributing to the full test group of 5-8 people.

Contingency: If label mismatches are found during TestFlight UAT, update BufdirReportStructureMapper constants and rebuild. Since the mapper is a pure Dart class with no persisted state, corrections are deployed in the next TestFlight build with no database migration required.