test-helpers

Test Helpers

Reads existing tests, finds repeated setup, and extracts that into a helper library so future tests stay short and intention-revealing.

---

Phase 1: Read Project Context

Read in parallel:

• .claude/docs/technical-preferences.md — Framework, Testing Framework, Naming Conventions.
• .claude/docs/coding-standards.md — test rules.
• tests/helpers/ (if present) — what already exists.

Confirm the framework. If unset, redirect to /setup-framework.

---

Phase 2: Scan Existing Tests

Glob the test tree:

• RN/TS: tests/**/*.test.{ts,tsx,js,jsx}
• Flutter: tests/**/*_test.dart and test/**/*_test.dart
• iOS: tests/**/*Tests.swift
• Android: tests/**/*Test.kt

For each file, find:

• Repeated factory functions (e.g., builders that return a User, Product, CartItem, etc.).
• Repeated mocks (network client, storage, analytics, deep-link router, push handler).
• Repeated assertion patterns (e.g., "the screen shows error X" or "the store dispatched action Y").
• Repeated setup/teardown blocks (auth state, seed data, navigation stack).

Group results by recurrence count. Anything that appears 3+ times is a candidate.

---

Phase 3: Propose the Helper API

Produce a proposal table:

Helper	Type	Used in	Reason
makeUser({...overrides})	Factory	8 tests	duplicated user objects
mockApiClient(responses)	Mock	5 tests	repeated fetch stubs
expectScreenShowsError(matcher)	Matcher	4 tests	repeated assertion

Use AskUserQuestion to confirm:

• [A] Generate every helper in the table
• [B] Generate only the top N
• [C] Let me pick — show one at a time

---

Phase 4: Write the Helpers

Create files under tests/helpers/ grouped by purpose. Always ask before each write. Naming follows the framework convention.

Factories — tests/helpers/factories/*

Pattern: pure functions that take an overrides object and return a fully-formed domain object with sensible defaults.