Unit Test Double-Export Guard Atomicity

The critical test to get right is the atomicity test. To simulate a mid-transaction failure, inject a mock Supabase client that succeeds for the first N mark calls and throws on the (N+1)th — then assert zero rows are updated in the database. This requires the guard's mark implementation to use a database transaction (Supabase RPC or batch operation with rollback). For the concurrency test, use Dart isolates or async futures launched concurrently with Future.wait and assert that only one export run record is created.

Use a test fixture builder (a helper function that creates seeded claim records) to avoid repetitive setup across test cases. Name tests descriptively: 'given 3 previously exported claims and 2 new claims, filterBatch returns only the 2 new claims'. Avoid test interdependence — each test must set up and tear down its own database state.

Three-layer test strategy: (1) Pure unit tests with fully mocked dependencies test the guard's filtering logic and return types in isolation. (2) Repository-level integration tests with a real local Supabase PostgreSQL instance test atomicity and transaction rollback. (3) Concurrency tests using Dart's Future.wait to simulate simultaneous export attempts. Use flutter_test as the test runner.

Use mocktail (preferred over mockito for null-safety ergonomics) for mocking the Supabase client in unit tests. Each test file maps 1:1 to the source class under test. 100% coverage required on DoubleExportGuard.