Testing and code structuring practices for the gt-cloud monorepo. RULE - Use whenever writing or reviewing tests, deciding what (or whether) to test, extracting logic from I/O-heavy code, or structuring a new module that mixes logic with Prisma/S3/LLM/network calls. The .agents/skills/gt-testing directory is the source of truth for these rules.
This skill is the canonical guidance for how code is structured for testability and how tests are written in this repo. The core principle is functional core, imperative shell: logic that makes decisions or transforms data lives in pure functions; I/O (Prisma, S3, Redis, LLM calls, octokit, fetch) lives in thin shells that gather inputs and execute results.
references/testing-patterns.md.references/code-structure.md.references/anti-patterns.md — several of these patterns have caused real drift in this repo.references/code-structure.md — when to extract pure functions, where extracted modules live, the 'use server' constraint, duplication rules.references/testing-patterns.md — what deserves a test, fixture/table-driven style, the mock policy, vitest mechanics, exemplar test files to copy.references/anti-patterns.md — concrete failure modes found in this repo: mocked pure functions that drifted, tests that reimplement the code under test, placeholder tests, call-mirroring assertions.expect(true).toBe(true), expect(fn).toBeDefined()). A package with no tests should say so honestly (vitest --passWithNoTests), not fake green.createTranslatedFile was called with the exact 13-field object the implementation builds is a tautology; it breaks on refactors and catches no bugs. Assert outputs and observable behavior instead.references/anti-patterns.md is a variant of a test that could never fail; this is the cheap defense against all of them.