Community Event Platform — bounswe2026group9

Our test data strategy follows an integration-first philosophy: tests run against a real Supabase PostgreSQL database rather than isolated mocks. This ensures that schema constraints (NOT NULL, FK, CHECK), triggers, and pg_cron jobs (e.g. the automatic transition to ended) are validated under real behavior. Only external side-effects (SMTP, OAuth callbacks, Supabase storage uploads) are mocked for determinism.

The strategy is defined across three layers:

Each test run produces its own isolated data space. From backend/tests_support.py:

TEST_RUN_ID = _normalized_run_id()        # CI run id or uuid hex[:8]
USERNAME_RUN_ID = TEST_RUN_ID[:6]

def build_test_identity(prefix):
    unique = uuid.uuid4().hex[:8]
    username = f"{prefix}_{USERNAME_RUN_ID}_{unique}"
    email    = f"{prefix}_{TEST_RUN_ID}_{unique}@example.com"
    return username, email

def cleanup_email_pattern():
    return f"%_{TEST_RUN_ID}_%@example.com"

• Prefix convention: testuser_, eventtest_, imgtest_, notiftest_ — every domain uses its own prefix.
• Cleanup: the autouse=True fixture in conftest.py deletes test data via LIKE pattern after each test; FK cascades remove related events / comments / notifications.
• No collisions: parallel CI jobs receive different TEST_RUN_IDs and therefore never interfere even when sharing tables.

Suggested events, recommendations, and notification flows cannot be tested without a meaningful history. A new backend/seed/scenario_seed.py provides:

The seed is gated by a SEED_SCENARIO=1 env variable; it runs only against staging / test Supabase projects to prevent any leakage into production.

Because the L3 seed is expensive, a versioned snapshot is produced via pg_dump (backend/seed/snapshots/<date>.sql.gz). E2E runs pg_restore first, so every PR is tested against the same baseline and the flaky-test surface shrinks.

Mocked components: SMTP (send_verification_email), OAuth callback, Supabase storage upload, and the pg_cron scheduler (fast-forwarded in E2E).

• Fixture pyramid: session-scoped DB client → function-scoped user/event factories → autouse cleanup.
• Builder helpers: _valid_event_body(), _create_published_event() — expose only override-able fields, sane defaults for the rest.
• Property-based smoke: hypothesis checks invariants such as start_datetime < end_datetime and capacity ≥ 0 against random inputs.

• API calls are intercepted with MSW handlers; their responses are derived from the same seed JSON snapshots, guaranteeing schema parity with the backend.
• Component tests rely on canned fixtures (frontend/tests/fixtures/events.json) instead of Faker so changes are easy to track.

• Repositories are tested with MockK; Retrofit responses come from the same seed JSON.
• UI tests use Compose createComposeRule(), with the same fixture set powering navigation and deep-link checks.

• Tools: Playwright (web) + Maestro (Android).
• Scope: not unit-level, but user journeys:
  1. Community Loop: register → going on three sports events → "Suggested" filter on Discovery surfaces sports events first → user receives a similar-event notification.
  2. Host Lifecycle: create draft → upload image → publish → reply to a comment → cancel → notification fan-out.
  3. Private Access: join via invite token → access request → host approval.
  4. Capacity & Age Gate: "Going" blocked on a full event + 18+ underage block.

Test data is not "valid because it was generated"; it must demonstrate production-like behavior. Validation is performed in three layers:

A run that deviates from the target by more than ±20% is treated as a "stale seed" and the snapshot is regenerated.

• Performance: with 10K events seeded → discovery search p95 < 2 s (k6 load test).
• Reliability: under 500 concurrent simulated users, HTTP 5xx rate < 1%.
• Visibility: cancelling an event → it disappears from Discovery within 60 s (polling test).

Each named user scenario is walked through against the seed:

Each scenario is captured as assertion + screenshot in the Playwright report; the demo flow is reproducible without manual UAT.

• backend/sql/0**.sql migrations are run against a clean DB on every CI build.
• The seed file is validated with pydantic models, so any backend response-model change makes the seed generator fail fast.