[rd-code-23]

Summary

• replace repeated public-user objects with typed test factories
• replace four duplicated API session configurations with one shared fixture
• document when test data should be shared and when it should remain local

Problem

Several tests repeated the same complete public-user object and secure session configuration. If the shared shape or default configuration changed, every copy would need to be found and updated independently. That creates unnecessary maintenance and makes it easier for test setup to drift.

How it works

The web and API now each have a typed createPublicUser() factory under their own src/test/fixtures/ directory. Tests can use the standard valid user or override only the field relevant to a scenario:

const userWithoutName = createPublicUser({ displayName: null });

The API also has one testSessionConfiguration fixture used by the four tests that require the same cookie, duration, and secret settings.

Why factories use overrides

Partial<PublicUser> overrides preserve a valid default object while making scenario differences visible at the call site. Tests do not need to repeat irrelevant fields just to change one property.

Why API and web fixtures remain separate

The API and web factories share the authoritative PublicUser type from @goforlift/contracts, so TypeScript enforces the same browser-safe shape.

Their actual test scenarios belong to different application boundaries and may evolve independently. Moving this small factory into a shared package would introduce cross-package test coupling and export configuration without enough reuse to justify it. The contract is shared; scenario defaults remain local.

What remains local

One-off values and data that explain the behavior of an individual test remain beside that test. This includes Google OIDC payloads, CSRF tokens, and route-specific helpers. Extracting those would hide information rather than improve maintainability.

Project convention

AGENTS.md now instructs future contributors and AI agents to:

• keep scenario-specific test data local
• extract stable domain objects or configuration repeated across test files
• prefer typed factories with explicit overrides for variants
• avoid sharing fixtures across unrelated application boundaries

Verification

• 48 API tests passed
• 19 web tests passed
• TypeScript passed
• ESLint passed
• changed files passed formatting and diff checks