agentleFS
Sign inStart free
juandelossantosjuandelossantos/another-agent-skills/skills/test-driven-development/SKILL.md

test-driven-development

Skill1 starsChanged 11 days agoMITView on GitHub

Write tests first with RED-GREEN-REFACTOR cycle. Use when implementing logic, fixing bugs, or proving code works. Do NOT use for exploratory prototyping.

We split this skill into the rules it gives an agent

2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 179 edited versions we read keep these.

  • 2

    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. Distinctive:

    Write a failing test before writing the code that makes it pass.

    line 16
  2. Distinctive:

    After completing any implementation:

    line 140

“Common” is measured: kept by at least 6 in 10 of the 179 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 a failing test before writing the code that makes it pass. For bug fixes, reproduce the bug with a test before attempting a fix. Tests are proof — "seems right" is not done.

When to Activate

  • Implementing any new logic or behavior
  • Fixing any bug (the Prove-It Pattern)
  • Modifying existing functionality
  • Adding edge case handling
  • User says "add tests" or "make sure it works"

When NOT to Use

  • Pure configuration changes, documentation updates, or static content changes

Output Contract

ArtifactFormatLocationQuality Criteria
Test files + tested source codeTest files (framework-agnostic) + modified source codetests/ or alongside source (any project structure)Test-first (RED→GREEN→REFACTOR) for every behavior change, bug fixes include reproduction test before fix, all tests passing, test names describe behavior (not implementation), no skipped/disabled tests, no empty tests (assert on behavior, not just "no error")

Decision Tree: What Kind of Test?

What are you testing?
├── Single function, pure logic → Unit test
│   ├── Input/output, no side effects
│   ├── Fast, isolated, many cases
│   └── ~80% of your test suite
│
├── Multiple units working together → Integration test
│   ├── API endpoint + database
│   ├── Component + service layer
│   ├── ~15% of your test suite
│   └── Test real interactions, not mocks
│
├── User flow through the app → E2E test
│   ├── Click through a complete workflow
│   ├── Login → create item → see it in list
│   ├── ~5% of your test suite
│   └── Use sparingly — slow, brittle
│
└── Bug fix → Prove-It Pattern
    ├── Write test that reproduces the bug
    ├── Test fails (proves the bug exists)
    ├── Fix the bug
    ├── Test passes (proves the fix works)
    └── Add to regression suite

Core Workflows

TDD Cycle

→ See guides/TDD-CYCLE.md

RED (write failing test) → GREEN (minimal code to pass) → REFACTOR (clean up)

Prove-It Pattern

→ See guides/PROVE-IT.md

For bug fixes: write test that reproduces the bug, then fix.

Test Pyramid

→ See guides/TEST-PYRAMID.md

Unit tests (~80%) → Integration (~15%) → E2E (~5%)

Writing Good Tests

→ See guides/WRITING-TESTS.md

State vs interactions, DAMP, AAA pattern, test naming.

Anti-Patterns

→ See guides/ANTI-PATTERNS.md

Empty tests, testing implementation, over-mocking, test interdependence.

Browser Testing

→ See guides/BROWSER-TESTING.md

DevTools workflow, security boundaries, when to use E2E vs integration.

Quick Reference

TDD Cycle:

RED: Write test that fails
GREEN: Minimal code to pass
REFACTOR: Clean up, tests still pass

Prove-It Pattern:

Bug → Write failing test → Fix → Test passes → Full suite

Empty Test Detection (from METR study):

Test passes but doesn't prove anything?
├── Does it assert on behavior (not implementation)? → Good
├── Does it test the actual output? → Good
├── Does it only call the function and check "no error"? → EMPTY TEST — rewrite
└── Does it use mocks for everything? → Likely testing mocks, not code

Framework Quick Start

FrameworkRun testsWatch modeCoverage
Jest/Vitestnpm testnpm test -- --watchnpm test -- --coverage
pytestpytestpytest --looponfailpytest --cov
cargo testcargo testcargo watch -x testcargo tarpaulin
Gogo test ./...go test -count=1 ./...go test -cover

Integration

SkillWhen to use with TDD
debugging-and-error-recoveryWrite failing test to reproduce bug, then debug
code-review-and-qualityReview test quality alongside code quality
incremental-implementationEach increment = one RED→GREEN→REFACTOR cycle
doubt-driven-developmentChallenge test assumptions before writing

Verification

After completing any implementation:

  • Every new behavior has a corresponding test
  • All tests pass
  • Bug fixes include a reproduction test
  • Test names describe the behavior being verified
  • No tests were skipped or disabled
  • No empty tests (tests that pass without asserting anything real)

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.

Reviews can't be read right now.

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