Write integration tests for full claim submission lifecycle
epic-mileage-reimbursement-entry-claim-orchestration-task-008 — Write integration tests against a real Supabase test database instance covering the full submitClaim() lifecycle: form input assembly → status resolution → persistence → cache update. Verify correct ClaimStatus values written to the database for both auto-approval and pending-review scenarios. Verify cache update-on-success path writes the expected prefill entry. Confirm no coordinator notification row is created for silent approvals.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 7 - 84 tasks
Can start after Tier 6 completes
Implementation Notes
Create a `test/helpers/supabase_test_client.dart` factory that reads environment variables and returns a configured SupabaseClient. Each test should generate a unique `testRunId = const Uuid().v4()` in setUp() and inject it into all created entities (e.g., as an external_ref or metadata field) for reliable cleanup. The integration test should use the real MileageClaimService with real repository implementations — only the Supabase client is pointed at the test project. For the 'no coordinator notification' assertion, query the notifications table and filter by claim_id: expect the result to be empty.
If the coordinator_notifications table does not yet exist, coordinate with the persistence task owners before writing this assertion. Avoid asserting on row count of the entire table — always filter by test-owned IDs.
Testing Requirements
Integration tests use flutter_test with the full Supabase Dart client wired to a test project. Tag tests with `@Tags(['integration'])` to separate them from unit tests. Use a `testSupabaseClient` fixture initialized once per test file in `setUpAll()`. Each test must perform cleanup in `tearDown()` using DELETE WHERE test_run_id =
Do not use transactions that auto-rollback — verify data was actually written then clean up explicitly, as this tests the real persistence path. Run with: `flutter test --tags integration`. In CI, set environment variables for the test Supabase credentials and gate these tests on a separate pipeline step from unit tests.
The auto-approval rule requires checking whether any additional expense lines are attached to the claim. The interface between the mileage claim and any co-submitted expense items is not fully defined within this feature's component scope. If the domain model does not include an explicit additionalExpenses collection, the evaluator cannot make a correct determination, which could auto-approve claims that should require manual review.
Mitigation & Contingency
Mitigation: Define the MileageClaim domain object interface with an explicit additionalExpenses: List field (nullable/empty for mileage-only claims) before implementing the service. Coordinate with the Expense Type Selection feature team to agree on the shared domain contract.
Contingency: If the cross-feature contract cannot be finalised before implementation, implement the evaluator to treat any non-null additionalExpenses list as requiring manual review and document the assumption for review during integration testing.
A peer mentor who taps the submit button multiple times rapidly (e.g. due to slow network) could cause MileageClaimService to be invoked concurrently, resulting in duplicate claim records being persisted with the same trip data.
Mitigation & Contingency
Mitigation: Implement a submission-in-progress guard in MileageClaimService using a BLoC/Cubit state flag that prevents re-entrant calls. The UI layer (implemented in Epic 4) will also disable the submit button during processing.
Contingency: Add a Supabase-level unique constraint or idempotency key on (user_id, origin, distance, submitted_at truncated to minute) to prevent duplicate rows reaching the database even if the application guard fails.