Write unit and integration tests for adapter

epic-multi-chapter-membership-handling-foundation-task-006 — Write flutter_test unit tests for the ContactChapter domain mapper covering all field mappings and edge cases. Write integration tests for the SupabaseContactChapterAdapter methods against a local Supabase instance or mocked PostgREST client, verifying that CRUD operations return correctly mapped domain objects, RLS filter clauses are appended as expected, and error paths throw typed exceptions.

high priority medium complexity testing pending testing specialist Tier 4

Acceptance Criteria

Domain mapper unit tests cover: all required fields present, all optional fields null, maximum 5 chapters, unexpected extra JSON keys ignored, missing required field throws MappingException

Adapter unit tests mock the PostgREST client and assert: create appends correct org filter, read returns mapped domain object, update patches only changed fields, delete removes the correct row, each method throws a typed ContactChapterException on Supabase error response

Integration tests run against Supabase CLI local instance (or equivalent) and verify end-to-end CRUD with real PostgREST execution

Integration test for cross-org isolation: seed two orgs, query with org A context, assert zero rows from org B are returned

Integration test for 5-chapter maximum: seed a contact with 5 chapters; attempt to insert a 6th and assert the appropriate constraint violation is surfaced as a typed exception

All tests pass with `flutter test` on CI without external network calls (unit tests use mocks; integration tests use local Supabase CLI)

Test file naming follows project convention: `*_test.dart` under `test/` mirroring `lib/` directory structure

Minimum 90% branch coverage on the mapper class; minimum 80% branch coverage on the adapter class

Technical Requirements

frameworks

Flutter

flutter_test

mockito or mocktail (whichever the project uses)

Supabase CLI (for local integration tests)

apis

Supabase PostgREST (mocked in unit tests, real in integration tests)

data models

ContactChapter

ContactChapterMapper

SupabaseContactChapterAdapter

OrganisationContext

performance requirements

Full unit test suite must complete in under 10 seconds

Integration test suite must complete in under 60 seconds against a local Supabase instance

security requirements

No real Supabase credentials in test code; use environment variables or Supabase CLI local keys only

Test fixtures must not include real personal data (use generated/fake identifiers)

Execution Context

Execution Tier

Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

View Full Execution Plan

Implementation Notes

Prefer mocktail over mockito if the project already uses it (no code-gen required). For integration tests, store the local Supabase URL and anon key as constants in a `test/helpers/supabase_test_client.dart` file — never hardcode in individual test files. Use a `test/fixtures/contact_chapters.sql` seed file for consistent test data; run it in `setUpAll` and clean up in `tearDownAll`. For the mapper, test JSON round-trip: `mapper.fromJson(mapper.toJson(entity)) == entity`.

Tag integration tests with `@Tags(['integration'])` so they can be excluded from fast unit-test runs in CI. Structure test file as: mapper tests first (pure, no I/O), then adapter unit tests (mocked I/O), then integration tests (real I/O) — this ordering helps diagnose failures at the lowest layer first.

Testing Requirements

Unit tests (flutter_test with mocktail/mockito): test ContactChapterMapper.fromJson with 6+ scenarios (happy path, nulls, extra keys, missing required keys). Test each public adapter method with a mocked SupabaseClient; use ArgumentMatchers to assert filter clauses. Integration tests: use Supabase CLI (`supabase start`) to spin up a local instance seeded via SQL fixture files. Run adapter CRUD operations and assert domain object correctness.

Include a cross-org isolation test and a 5-chapter constraint test. Group tests with `group()` blocks matching class names. Use `setUp`/`tearDown` for database cleanup in integration tests.

Component

Supabase Contact Chapter Adapter

infrastructure medium

Dependencies (1)

Extend the adapter to include organisation-scoped query filters that complement the RLS policies, providing defence-in-depth. Implement a method that accepts an organisation context parameter and appends the appropriate PostgREST filter clauses. Ensure queries remain efficient by leveraging the indexes created in the migration step. epic-multi-chapter-membership-handling-foundation-task-005

Epic Risks (2)

high impact medium prob security

Supabase RLS policies for a junction table that spans organisations are non-trivial. An incorrectly scoped policy could expose chapter affiliations from other organisations to coordinators, constituting a data breach.

Mitigation & Contingency

Mitigation: Draft RLS policies in a staging environment and run an explicit cross-organisation isolation test suite before merging. Use Supabase policy testing tools and peer review all policy definitions.

Contingency: If a policy error reaches review, roll back the migration and apply a corrective patch. Ensure no production data has been exposed by auditing Supabase logs for cross-organisation query results.

medium impact medium prob technical

The contact_chapters table migration may conflict with existing foreign key structures or require a backfill for contacts already assigned to a single chapter, causing migration failures in production.

Mitigation & Contingency

Mitigation: Write the migration as an additive, non-destructive operation. Backfill existing single-chapter assignments by deriving them from the existing contact records. Test the full migration on a production-sized dataset clone before release.

Contingency: Provide a rollback migration script that removes the new table without touching existing contact records. Coordinate with operations for a maintenance window if a re-run is needed.

Quick Links

All Tasks Execution Plan