Widget Tests for ProxyAuditBadge and Integration Smoke Test
epic-bulk-and-proxy-registration-foundation-task-010 — Write widget tests for ProxyAuditBadge using flutter_test: verify badge renders when IDs differ, verify nothing renders when IDs match, verify semantic label is present for screen readers, and verify design-token colors are applied. Additionally run a smoke integration test against a local Supabase instance that inserts one batch of two proxy activity records (recorded_by_user_id set to coordinator) and asserts the badge appears on both resulting activity cards.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
For the design token color assertion, avoid asserting a hardcoded hex — import the token constant directly in the test file and compare `Color == AppDesignTokens.proxyBadgeColor`. This ensures the test breaks if someone changes the token value without updating the badge. For the integration test setup, consider a `setUpAll` block that calls the Supabase admin API to insert test records and a `tearDownAll` that deletes them by test-run ID. Use a unique `test_run_id` metadata field on seeded records to avoid cross-test contamination.
The integration test must boot the full Flutter widget tree (use `IntegrationTestWidgetsFlutterBinding.ensureInitialized()`). Tag it so it does not run in standard `flutter test` — only via `flutter test integration_test/` explicitly.
Testing Requirements
Widget tests: use `WidgetTester.pumpWidget()` wrapping ProxyAuditBadge in a `MaterialApp` with the design token theme applied. Use `find.byType()`, `find.bySemanticsLabel()`, and `find.byWidgetPredicate()` to assert rendering and semantics. Color assertion: use `tester.widget
Use a test helper to seed the local Supabase database before the test and clean up after. Pump the full activity list screen and use `find.byType(ProxyAuditBadge)` to count badge occurrences.
Adding recorded_by_user_id to the activities table and writing correct RLS policies is error-prone: overly permissive policies would allow coordinators to record activities under arbitrary user IDs they do not manage, while overly restrictive policies would silently block valid proxy inserts. A policy defect here would either create a security vulnerability or break the entire proxy feature at runtime.
Mitigation & Contingency
Mitigation: Write RLS policies in a local Supabase emulator first. Include policy unit tests using pg_tap or supabase test helpers. Have a second reviewer check the migration SQL before merging. Explicitly test the three cases: coordinator inserting for their own mentors (should succeed), coordinator inserting for another chapter's mentors (should fail), peer mentor inserting for themselves (should succeed as before).
Contingency: If a policy defect is discovered in staging, roll back the migration with a down-migration script. Delay feature release until the policy is corrected and re-verified. Apply a feature flag to keep the proxy entry point hidden from coordinators until the fix is confirmed.
The insert_bulk_activities RPC must behave atomically — a failure on row 7 of 12 must roll back rows 1–6. If Supabase's RPC transaction handling is misconfigured or if network interruptions cause partial acknowledgements, some peer mentors could receive duplicate or missing activity records, directly corrupting Bufdir statistics for the coordinator's chapter.
Mitigation & Contingency
Mitigation: Implement the RPC as a PostgreSQL function with explicit BEGIN/EXCEPTION/END block to guarantee atomicity. Add an integration test that inserts a batch where one row violates a unique constraint and asserts zero rows are committed. Document the transaction semantics in code comments.
Contingency: If atomicity cannot be guaranteed via RPC (e.g., due to Supabase plan limitations), fall back to a sequential insert loop with a compensating DELETE in case of partial failure, and surface a clear error to the coordinator listing which mentors failed and which succeeded.