Widget and integration tests for approval UI components
epic-expense-approval-workflow-bulk-and-action-task-012 — Write widget tests for BulkApprovalBar covering visibility toggling on selection change, button disabled state during processing, and count badge updates. Write widget tests for ApprovalActionSheet covering rejection comment enforcement, confirmation step flow, and accessible semantics labels for WCAG 2.2 AA compliance. Run integration test for full single-claim approve flow through the sheet.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
Structure the test file in three groups: 'BulkApprovalBar widget tests', 'ApprovalActionSheet widget tests', 'Approval integration tests'. For WCAG 2.2 AA semantics testing: every interactive element needs a Semantics label — use Semantics(label: 'Approve claim ${claim.id}', button: true, child: ...) pattern on action buttons. The integration test should use the integration_test package (not flutter_driver which is legacy). Wrap integration test main() with IntegrationTestWidgetsFlutterBinding.ensureInitialized().
For Supabase test environment isolation: use a separate test organization ID seeded in migrations. Keep the integration test in a separate file (integration_test/ directory) from widget tests (test/ directory) per Flutter conventions. BulkApprovalBar visibility should be tested with AnimatedSwitcher or Visibility — find the widget via find.byType(BulkApprovalBar).evaluate().isNotEmpty.
Testing Requirements
Widget tests: use flutter_test WidgetTester with BlocProvider wrapping MockBloc (mocktail). Use tester.tap(find.byType(ElevatedButton)) and pumpAndSettle. For semantics tests, use tester.getSemantics(find.byType(AppButton)) and verify SemanticsData.label is non-empty and meaningful. For WCAG: use flutter_test's SemanticsHandle (tester.ensureSemantics()) before semantic assertions.
Integration test: use flutter_driver or integration_test package. Seed test data in Supabase test environment in setUp, clean up in tearDown. Verify claim status change via Supabase client query after sheet closes.
If a bulk approval batch partially fails (some claims approved, some failed), the UI must communicate which specific claims failed without overwhelming the coordinator. A poorly designed error display could cause coordinators to re-approve already-approved claims or miss claims that still need attention.
Mitigation & Contingency
Mitigation: Design the BulkApprovalResult display to show a clear summary (e.g., '14 approved, 2 failed') with a collapsible list of failed claims including their IDs and submitter names. Failed claims should remain selected in the queue so the coordinator can retry them individually.
Contingency: If the summary UI proves insufficient, add a dedicated 'bulk action history' sheet showing the last bulk operation result, accessible from the queue screen header.
If the app is backgrounded or the network drops while the coordinator has the ApprovalActionSheet open mid-decision, the typed comment could be lost and the transition state could be ambiguous, potentially causing a coordinator to believe they approved a claim that was never submitted.
Mitigation & Contingency
Mitigation: Persist the in-progress action sheet state (selected action + comment text) to a local draft store keyed on claim ID. On sheet re-open for the same claim, restore the draft. After confirmed submission, verify the resulting claim status from the server before dismissing the sheet.
Contingency: On network error during submission, display a persistent retry banner within the sheet rather than dismissing it, so the coordinator can resubmit without re-entering their comment.