tdd

name	tdd
description	Use test-driven development for behavior-changing feature or fix work, and whenever the user mentions TDD, test-first, red-green-refactor, tracer bullets, integration tests, or public-interface behavior tests. Skip for docs-only, path-only rename, formatting-only, or purely mechanical chores unless explicitly requested.
license	MIT
compatibility	Requires bun for Plaited repository validation

Test-Driven Development

Core Rule

Work in vertical red-green-refactor slices:

1. RED: write one test for one observable behavior.
2. GREEN: implement the smallest production change that makes that test pass.
3. REFACTOR: clean up only while tests are green.

Do not write a batch of imagined tests before implementation. Each new test should respond to what the last cycle taught you about the actual behavior and interface.

Plaited Defaults

• Use bun test for targeted tests and bun --bun tsc --noEmit for the type gate.
• Use test, not it, and organize with describe.
• Prefer real dependencies and real runtime boundaries over mocks.
• Mock only external boundaries such as remote APIs, time, randomness, or rare filesystem cases.
• Avoid conditional assertions: assert the branch first, then assert branch-specific values.