Developing Features Tdd

---
name: developing-features-tdd
description: Build a new feature using strict test-driven development — UNDERSTAND → DESIGN → RED → VERIFY RED → GREEN → VERIFY GREEN → REFACTOR → VALIDATE → REPEAT. Use when building a new feature with TDD, when the user says "TDD this", "tests first", "red green refactor", or asks for feature work that needs to be verifiable from the spec. For bug fixes use fixing-bugs; for non-TDD production code use developing-features.
license: MIT
---

# Developing Features with TDD

Test-driven feature development. Every observable behavior is driven by a failing test that goes RED → GREEN, with architecture planned before the first test is written.

> **Never write production code for a new feature before proving its expected behavior with a failing test.**

## Read first (always)

List `learnings/` and read every file relevant to the current feature. Project-specific test conventions, framework quirks, or constraints live there and override the defaults in this SKILL.md. If a learning conflicts with this file, **the learning wins** — mention it to the user.

## Tradeoff — when to apply, when to lighten up

Apply the full nine-phase cycle for **production features** the user explicitly asks to build with TDD, or for code paths where regressions are expensive (payments, auth, data integrity, AI runtime, public APIs).

Lighten the formality for one-off scripts, throwaway exploration, prototypes the user has labeled as such, or features under 30 lines of production code. Still write at least one happy-path test and one adversarial test — but skip the explicit Phase 2 design document.

## Best practices — inherited from `developing-features` (this skill changes only the *how*)

Every engineering standard in `developing-features` applies here **in full and unchanged**. TDD changes *how* you implement (test-first: RED → GREEN → REFACTOR), not *what* "good" means — it never relaxes or replaces these:

- The **pre-implementation security check**, the **reuse ladder** (existing code → stdlib → platform → installed dep → only then new code), the **trade-off priority** (correctness → simplicity → testability → performance → reuse), and the **core code-quality rules**: SOLID, DRY/KISS/YAGNI/Law of Demeter, file-structure hard limits, intention-revealing naming, immutability, no global state, strong typing, guard clauses, complexity ≤ 10 / nesting ≤ 4, and no-WHAT-comments.
- **Error handling**, **security**, **observability**, **data layer & scale** (pooling, indexes, no-N+1, pagination), and **platform-agnostic** rules.
- Their full detail lives in `developing-features/references/{security,solid,pragmatic-principles,file-structure,observability,data-layer}.md` — read them as needed.

The phases below weave these into the RED/GREEN/REFACTOR/VALIDATE loop; they are the **same bar**, reached test-first.

## The cycle (strict order)

```
1. UNDERSTAND     →  Decompose requirements (Given/When/Then) + threat model
2. DESIGN         →  Plan architecture (files, layers, responsibilities) BEFORE coding
3. RED            →  Write a failing test for the next slice of behavior
4. VERIFY RED     →  Run the test — it MUST fail, for the right reason
5. GREEN          →  Write the MINIMUM production code that makes it pass
6. VERIFY GREEN   →  Run the test — it MUST now pass
7. REFACTOR       →  Clean up, apply SOLID/DRY/KISS — tests stay GREEN
8. VALIDATE       →  Run ALL tests; coverage ≥ 75% (target 80%); linters/formatters pass
9. REPEAT         →  Next slice (steps 3–8) until all acceptance criteria are covered
```

If you skip steps or change the order, the feature is invalid. The phases are detailed in `references/cycle.md`.

## Phase 1 — UNDERSTAND

Before opening the editor, you must be able to answer:

| Question                                                                | Why                                                  |
|-------------------------------------------------------------------------|------------------------------------------------------|
| What problem does this feature solve?                                   | Defines success criteria                              |
| Who is the user/actor?                                                  | Defines API surface and permissions                   |
| What are the explicit acceptance criteria?                              | Defines what tests must prove                         |
| What are the inputs, outputs, and side effects?                         | Defines function/service contracts                    |
| What can go wrong (errors, edge cases, abuse)?                          | Defines adversarial tests                             |
| What systems does this touch (DB, APIs, AI, queues)?                    | Defines integration boundaries                        |
| What is the security blast radius if this misbehaves?                   | Drives the threat model                               |

For each acceptance criterion, write:

```
GIVEN:    <precondition / initial state>
WHEN:     <action the user/system performs>
THEN:     <expected observable behavior>
SO THAT:  <business value>
```

If any criterion cannot be decomposed → **ask for clarification**. Don't guess scope.

**Pre-implementation security check** — the same questions from the `developing-features` skill apply (all of them). If the feature touches AI/LLM, webhooks, auth, or data persistence, the answers **must become adversarial tests** in Phase 3 before the corresponding production code exists.

## Phase 2 — DESIGN

TDD does not exempt you from designing first. Skipping design produces small green tests sitting on top of spaghetti architecture.

Before the first RED test, produce this design doc (in scratch notes, plan tool, or PR draft):

```
FEATURE: <name>

SLICES (in build order, smallest valuable behavior first):
  1. <slice 1>
  2. <slice 2>
  3. <...>

FILE STRUCTURE:
  - src/<area>/types/<feature>_types.<ext>
  - src/<area>/helpers/<feature>_validation.<ext>
  - src/<area>/services/<feature>_service.<ext>
  - src/<area>/repositories/<feature>_repository.<ext>
  - src/<area>/handlers/<feature>_handler.<ext>

DEPENDENCIES (injected, not instantiated):
  - <ServiceX> depends on abstraction <RepositoryY>

THREAT MODEL (must become tests):
  - <Threat 1> → test_should_<reject|deny|fail>_when_<condition>
  - <Threat 2> → ...

DURABILITY ANCHOR (where intent lives after this PR):
  - Test names encoding each acceptance criterion
  - PR description: ## Acceptance Criteria → Tests
  - ADR (only for non-obvious decisions): docs/adr/<NNNN>-<slug>.md

NON-OBVIOUS DESIGN DECISIONS (each must be anchored above):
  - <decision 1>: <why this over the alternative>
```

File-structure rules (hard limits, every language): see `developing-features` skill, `references/file-structure.md`. Layer rules (handler ≠ service ≠ repository ≠ helper ≠ client) apply throughout.

**If the feature calls an LLM at runtime**, the design also includes an AI runtime profile (timeout, circuit breaker, fallback, cost ceiling, kill switch, SLO). See `references/ai-runtime.md`. These items **become failure-mode tests** in Phase 3.

## Phase 3 — RED

Build the feature **one thin slice at a time**. One slice = one RED test = one minimal GREEN change.

**Slice order** (recommended):

1. Happy path of the smallest valuable behavior.
2. Edge cases (empty, null, boundary, max).
3. Error cases (invalid input, downstream failure, timeout).
4. Adversarial cases (forged input, replay, injection, scope bypass).
5. Integration seams (handler ↔ service ↔ repository) — only after unit slices are GREEN.
6. **AI runtime failure modes** (mandatory if the feature calls an LLM): timeout, malformed output, circuit open, rate limit / safety filter, kill switch toggled off.

**Each test must:**

- Assert observable behavior from the acceptance criteria, not implementation details.
- Be independent and deterministic — no shared mutable state, no order coupling.
- Mock or fake all external dependencies (DB, HTTP, filesystem, time, randomness).
- **Fail before the production code exists**, proving the behavior is missing.
- **Pass after the minimum production code is written**, proving the behavior is delivered.
- Use Arrange–Act–Assert (or Given–When–Then) structure.

**Test naming:** `should_[expected_behavior]_when_[condition]`. Examples and full quality rules in `references/test-quality.md`.

→ verify: the test runs the slice through its public surface, mocks all external deps, has one focused assertion (or one focused group), and the failure message clearly names the missing behavior.

## Phase 4 — VERIFY RED

Run the test. It MUST fail.

| Check                                                                 | Expected                                                       |
|-----------------------------------------------------------------------|----------------------------------------------------------------|
| Does the test fail?                                                   | Yes — must fail                                                |
| Is the failure reason "feature isn't built yet" shaped?               | `AttributeError`, `NotImplementedError`, missing module, etc.  |
| Is the assertion checking observable behavior, not internals?         | Yes                                                            |

If the test **passes** before the code exists, the assertion is trivially true — tighten it, or split the slice further.

If the test **fails for the wrong reason** (setup error, wrong wiring, unmet dependency from another slice), fix the test plumbing or split the slice — don't proceed to GREEN.

Document the RED state in scratch notes:
```
TEST: test_should_create_user_when_input_is_valid
STATUS: FAILED
REASON: AttributeError: 'UserService' object has no attribute 'create_user'
EXPECTED REASON: Yes — production code for this slice does not exist yet
```

## Phase 5 — GREEN

Write only enough code to make the current RED test pass. Do not implement future slices.

- Change/add the **minimum** code necessary.
- Place code in the file decided in Phase 2. If you find you need a file you didn't plan, pause and revise the plan — don't dump it in a generic `utils`.
- Follow the layer rules from Phase 2 (handler ≠ service ≠ repository ≠ helper ≠ client).
- Inject dependencies via constructors/parameters; never instantiate infrastructure inside business logic.
- Do **not** add features not driven by the current RED test.
- Do **not** pre-build retry policies, caches, plugin systems, or configuration knobs "for later" (YAGNI).

**Architectural rules that apply even in GREEN** (cannot be deferred to REFACTOR):

- SRP (one sentence without "and"/"or"), DIP (depend on abstractions), no global state, strong typing (no `any`/`object`/`dynamic`), no magic numbers, early returns / guard clauses, no silent failures, no secrets in logs.
- Cyclomatic complexity ≤ 10 in new functions; nesting depth ≤ 4. If a slice forces a violation, the design is wrong — return to Phase 2.

If GREEN forces violation of any of these, the **design is wrong** — return to Phase 2, don't push through.

## Phase 6 — VERIFY GREEN

Run the same test from Phase 3. It MUST now pass.

| Check                                                          | Expected |
|----------------------------------------------------------------|----------|
| Does the previously failing test now pass?                     | Yes      |
| Did you write the minimum code to make it pass?                | Yes — no scope creep |
| Did you respect the planned file structure and layers?         | Yes      |
| Are dependencies injected, not hard-wired?                     | Yes      |

## Phase 7 — REFACTOR

Refactor **only** when tests are GREEN. After every small step, re-run tests.

| Smell                                                                  | Refactor                                                  |
|------------------------------------------------------------------------|------------------------------------------------------------|
| Duplicated logic across 2+ places (5+ lines, same intent)              | Extract to a named helper                                  |
| `if/elif` chain on a type/category with 3+ branches                    | Strategy / polymorphism (OCP)                              |
| Function describable only with "and"/"or"                              | Split into two (SRP)                                       |
| Long call chain (`a.b.c.d.method()`)                                   | Encapsulate behind a method on the direct collaborator     |
| Magic number/string                                                    | Named constant                                             |
| Deep nesting                                                           | Early returns / guard clauses                              |
| Mixed responsibility prefixes in one file                              | Split file by responsibility                               |
| Bloated interface (most implementors stub methods)                     | Split into smaller interfaces (ISP)                        |

**Refactoring rules:**
- Small incremental steps — one transformation at a time.
- Run tests after each change.
- No new behavior — refactors must not alter what tests assert.
- Separate commit from slice implementation.
- Prefer duplication over wrong abstraction.

## Phase 8 — VALIDATE

Run the FULL test suite. All tests must pass. New + pre-existing.

- [ ] All new tests pass; all pre-existing tests still pass.
- [ ] Linter, formatter, type checker pass for every language touched.
- [ ] No `any`/`object`/`dynamic` introduced; no suppressed lint rules without a `Why:` comment.
- [ ] **Cyclomatic complexity ≤ 10** in new functions; **nesting ≤ 4**.
- [ ] **Coverage ≥ 75% (target 80%)** — branch coverage, shown to the user.
- [ ] Platform-agnostic checks pass (see `ensuring-cross-platform` skill).
- [ ] **If it touches a DB:** pooled connection with limits, indexes on FK / filter columns, no N+1, lists paginated (see `developing-features/references/data-layer.md`).
- [ ] **AI runtime resilience tests pass** if the feature calls an LLM (timeout → fallback, malformed output → graceful error, circuit-open → bypass, kill switch → deterministic disable).
- [ ] **Comprehension gate** — you can defend every significant block of the diff without re-reading it.
- [ ] **Architectural intent is captured** for every non-obvious decision (test name, `Why:` comment, PR `## Design Decisions`, or ADR).

If existing tests break:

1. **Analyze** — is the breaking test correct, or was it asserting behavior your feature legitimately changed?
2. If the test was right → your feature has a regression. Return to Phase 5 / 7.
3. If the requirement legitimately changed → update the test in the same PR with a clear `Why:` in the commit description.
4. **Never delete a failing test to make CI green.**

## Phase 9 — REPEAT

Pick the next slice from Phase 2 (or refine if you learned something). Return to Phase 3.

**The feature is done when:**

- Every acceptance criterion maps to ≥1 passing test.
- Every threat-model item maps to ≥1 passing adversarial test.
- All architectural rules are satisfied.
- Coverage ≥ 75% (target 80%).
- All linters/formatters/type checkers pass.
- CI matrix passes on every supported OS (see `ensuring-cross-platform`).

## Tests are permanent

The tests you wrote during the RED→GREEN cycle are **the executable specification** of this feature. Never delete a feature test unless the feature is removed. If a future PR breaks one, either fix the PR or update the test in the same PR with `Why:` documentation.

## Final step: capture a learning

Before closing the task, ask: *did I encounter a TDD-relevant constraint, framework quirk, or testing trap not in this SKILL.md or `references/`?* If yes, append a `learnings/YYYY-MM-DD-slug.md`. If no, skip.

## Output format

1. **Requirement decomposition** — Given/When/Then/So-That per acceptance criterion.
2. **Threat model** — risks → adversarial tests planned.
3. **Architecture plan** — file structure, layers, dependencies (Phase 2 output).
4. **Slice-by-slice build** — for each slice: RED test → GREEN code → REFACTOR notes (if any).
5. **Final test run** — full suite passes, coverage shown.
6. **Brief explanation** — architectural decisions in 3–5 bullets.

## See also

- `references/cycle.md` — phase-by-phase detail with examples for each step.
- `references/test-quality.md` — naming convention, AAA structure, what to test / what NOT to test, anti-patterns.
- `references/ai-runtime.md` — AI runtime profile, mandatory failure-mode tests for LLM features.
- `references/checklist.md` — the full feature checklist + PR description template + commit format.
- `developing-features` skill — non-TDD production code rules (SOLID, security, file structure, observability, data layer) referenced throughout this skill; incl. `references/data-layer.md` (connection pooling, indexes, no-N+1, pagination).
- `ensuring-cross-platform` skill — portability rules that apply at RED, GREEN, REFACTOR, and VALIDATE.
- `writing-tests` skill — broader testing strategy (pyramid, integration, E2E, coverage).
- `learnings/` — project-specific TDD conventions accumulated over time.