agentleFS
Sign inStart free
jjmrochajjmrocha/coding-skills/test-driven-development/SKILL.md

test-driven-development

Skill1 starsChanged 30 days agoMITView on GitHub

Use when implementing any feature or bugfix, before writing production code. Triggers on "implement X", "add feature Y", "fix bug Z", "build a function that…", or when about to write production code without a failing test.

190 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use chinese-code-review, chinese-commit-conventions and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Leodorareluctant259Skill

    chinese-code-review

    中文代码审查规范——在保持专业严谨的同时，用符合国内团队文化的方式给出有效反馈

    Also in 8 projects that use this

  • Leodorareluctant259Skill

    chinese-commit-conventions

    中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化

    Also in 8 projects that use this

  • obraSkill

    diagnosing-superpowers

    Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.

    Also in 19 projects that use this

  • LLl0k0laDSkill

    using-agent-skills

    Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.

    Also in 39 projects that use this

  • LLl0k0laDSkill

    git-workflow-and-versioning

    Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.

    Also in 47 projects that use this

  • MrCipherSmithSkill

    constraint-driven-development

    Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.

    Also in 15 projects that use this

  • +3 more from Leodorareluctant259
  • +3 more from LLl0k0laD

The file

We split this skill into the rules it gives an agent

4 rules. 1 is common, 3 are distinctive, and 0 are very specific to this project.

  • 1

    Common

    Most of the 178 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Write the test first. Watch it fail.

    line 8
  2. Distinctive:

    Write one test for the next behavior.

    line 20
  3. Distinctive:

    Gate: Run it. It must fail for the *right* reason (function doesn't exist, assertion on expected behavior) — not a syntax error.

    line 22
  4. Distinctive:

    All of these mean: write the failing test, start over.

    line 80

“Common” is measured: kept by at least 6 in 10 of the 178 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test-Driven Development

Write the test first. Watch it fail. Write minimal code to pass. Clean up. Repeat.

Tests written before code specify what to build. Tests written after only confirm what you already built. The order is the whole point.

The Cycle

RED → GREEN → REFACTOR → repeat

RED — Write a failing test

Write one test for the next behavior. Use the API you wish existed.

Gate: Run it. It must fail for the right reason (function doesn't exist, assertion on expected behavior) — not a syntax error. If it passes, you're testing existing behavior; rewrite.

REQUIRED SUB-SKILL: Invoke writing-unit-tests before writing the test — scenario selection, naming, structure. Do not write test code without it.

GREEN — Write minimum code to pass

The smallest thing that makes the test pass. Not clever, not general — minimal. Every line beyond what the test requires is scope creep.

See coding-discipline — the scope creep and speculative complexity failure modes apply directly.

Gate: Full suite green. Every test, not just the new one.

REFACTOR — Clean up without adding behavior

Change how, not what.

Walk each item and report one line for it — what you changed, or "already clean":

  • Duplication — the same knowledge expressed in two places
  • Naming — does each name say what it is, not how it works?
  • Cognitive complexity — nesting depth, branch count, boolean operators per condition. Extract until the function reads top-to-bottom in one screen.
  • Single responsibility — does this function do one thing?
  • No side effects — mutation of arguments, globals, or receiver state that the name doesn't advertise
  • Dead code and speculative generality — delete it

For significant structural changes, load the refactoring-expert specialist from using-software-specialists.

Gate: the six lines above, then the suite green. Then write the next failing test.

Adapting to Existing Code

SituationWhat to do
New behavior in existing codeWrite failing test for new behavior first, then implement
Bug fixWrite a test that reproduces the bug, watch it fail, then fix. The test stays as a regression guard.
Refactoring existing codeCharacterize current behavior with tests first. Run them green on unmodified code. Then refactor with the suite as your safety net.
Starting freshWrite the test before any production code

Scenarios Where TDD Feels Hard

ExcuseReality
"I don't know the right interface yet"That's a signal. Write the test using the interface you wish existed. If the test is awkward to write, the interface is awkward to use.
"This is a UI / infrastructure / glue code"Adapt the grain, not the order. UI: test observable state. Infra: test the interface contract. Glue: test the wiring.
"The existing code has no tests"Characterize with tests first — that's your baseline. Then modify.
"Too simple to need a test"A 3-line test costs less than the future debugging session.
"Tests after achieve the same purpose"Tests-after confirm. Tests-before specify. Fundamentally different.
"This will slow me down"TDD is faster than: write → manually test → find bug → debug → fix → re-test.

Red Flags — Stop and Start Over

  • Code before test
  • "I already manually tested it"
  • "Tests after achieve the same purpose"
  • "It's about spirit not ritual"
  • "This is different because..."
  • "I'll add tests before the PR"

All of these mean: write the failing test, start over.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free