Write unit tests for SupabaseSearchRepository
epic-contact-search-data-layer-task-009 — Write unit tests for the SupabaseSearchRepository using a mocked Supabase client. Cover: name ilike match, organisation ilike match, notes keyword match, empty result handling, RLS-scoped filtering (results limited to user's organisation), and error propagation when Supabase is unreachable.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Supabase's Dart client uses a fluent builder pattern that is notoriously hard to mock because intermediate builder objects are returned. Use mocktail's `when(client.from(any)).thenReturn(mockQueryBuilder)` pattern and stub each chained method. Alternatively, wrap the Supabase query in an abstract SearchDataSource interface and mock the interface instead of the Supabase client directly — this is the recommended approach as it decouples tests from Supabase's internal builder API and makes tests resilient to SDK upgrades. The ContactSearchResult model returned by both online and offline repositories must be identical — include an assertion in the test that verifies the model fields match the expected schema to catch regressions if the model is changed.
Testing Requirements
Pure unit tests (no widget tree, no Supabase connection). Use mocktail or mockito to create a MockSupabaseClient and stub the query builder chain (from().select().ilike().execute() pattern). Each test case should: arrange the mock response, act by calling searchContacts(query, organisationId), assert on the returned List
})` and label each with a descriptive name matching the scenario. Aim for 100% branch coverage of the repository class — every conditional path (empty result, error, RLS filter) must have at least one test.
Supabase RLS policies may not correctly scope ilike search results to the authenticated user's organisation and chapter, causing data leakage across organisations or empty result sets for valid queries.
Mitigation & Contingency
Mitigation: Reuse and extend existing RLS query builder patterns from the contact-list-management feature. Write integration tests against a seeded multi-organisation test database to verify cross-org isolation before merging.
Contingency: If RLS scoping is insufficient, add an explicit organisation_id filter in the Dart query builder layer as a defence-in-depth measure while the Supabase policy is corrected.
Adding new Drift tables for the contact cache may conflict with existing migrations or schema versions in the contact-list-management feature if both features cache the same contacts table, causing migration failures on user devices.
Mitigation & Contingency
Mitigation: Audit existing Drift schema versions from contact-list-management before writing new migrations. Reuse existing cache tables if the schema already covers required fields; only add missing fields via ALTER or new version.
Contingency: If schema conflict occurs, consolidate into a single shared cache table owned by contact-list-management and expose a DAO interface to the search feature, avoiding duplicated schema ownership.
The offline cache may surface significantly stale contact data if sync has not run recently, leading coordinators to act on outdated information (wrong phone numbers, changed assignments).
Mitigation & Contingency
Mitigation: Store and surface the last-sync timestamp prominently in the UI layer. Trigger a background cache refresh on app foreground when connectivity is detected.
Contingency: If staleness becomes a reported UX issue, implement a maximum-age threshold that shows a warning banner when the cache is older than a configurable limit (e.g. 24 hours).