agentsclimarketplace

Test driven development

Skill itallstartedwithaidea/agent-skills/skills/software-dev/test-driven-development

Test-Driven Development enforces the RED-GREEN-REFACTOR discipline on every code change an agent produces.From its SKILL.md

Install
npx -y skills add itallstartedwithaidea/agent-skills --skill test-driven-development

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

5.2 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

Test-Driven Development

Part of Agent Skills™ by googleadsagent.ai™

Description

Test-Driven Development enforces the RED-GREEN-REFACTOR discipline on every code change an agent produces. The agent writes a failing test first, confirms the failure, writes the minimal code to pass, confirms the pass, refactors for clarity, and commits. No production code exists without a corresponding test that demanded its creation.

This skill eliminates the most common agent anti-pattern: generating large blocks of untested code that "look right" but silently break under edge cases. By forcing the agent through the TDD cycle, each line of production code is justified by a specific test assertion. The result is a codebase where test coverage is not an afterthought but a structural guarantee.

The cycle integrates directly with version control. Each RED-GREEN-REFACTOR iteration produces an atomic commit, creating a reviewable history of design decisions. The refactor phase is mandatory—the agent must evaluate naming, duplication, and structural clarity before moving to the next feature increment.

Use When

  • Writing any new function, method, or module
  • Fixing a bug (write the test that exposes the bug first)
  • Refactoring existing code (ensure tests pass before and after)
  • The user requests "TDD", "test-first", or "red-green-refactor"
  • Building APIs, data transformations, or business logic
  • You need confidence that a change does not introduce regressions

How It Works

graph LR
    R[RED: Write Failing Test] --> G[GREEN: Minimal Code to Pass]
    G --> RF[REFACTOR: Clean Up]
    RF --> C[COMMIT: Atomic Commit]
    C --> R
    style R fill:#e74c3c,color:#fff
    style G fill:#2ecc71,color:#fff
    style RF fill:#3498db,color:#fff
    style C fill:#95a5a6,color:#fff

RED: Write a test that describes the next small behavior increment. Run it. Confirm it fails for the expected reason—not a syntax error or import failure, but a genuine assertion failure. GREEN: Write the simplest production code that makes the test pass. Resist the urge to generalize. REFACTOR: Improve names, extract duplication, simplify control flow. All tests must still pass. COMMIT: Stage and commit with a message referencing the behavior added.

Implementation

# RED: Write the failing test first
def test_calculate_discount_applies_ten_percent_for_orders_over_100():
    order = Order(items=[Item(price=150.00)])
    result = calculate_discount(order)
    assert result == 135.00  # 10% off

# Run: pytest => FAIL (calculate_discount not defined)

# GREEN: Minimal implementation
def calculate_discount(order):
    total = sum(item.price for item in order.items)
    if total > 100:
        return total * 0.9
    return total

# Run: pytest => PASS

# REFACTOR: Extract magic numbers
DISCOUNT_THRESHOLD = 100
DISCOUNT_RATE = 0.10

def calculate_discount(order):
    total = sum(item.price for item in order.items)
    if total > DISCOUNT_THRESHOLD:
        return total * (1 - DISCOUNT_RATE)
    return total

# Run: pytest => PASS
# git commit -m "feat: apply 10% discount for orders over $100"

Anti-Patterns to Avoid

Anti-PatternWhy It Fails
Writing tests after codeTests confirm assumptions, not behavior
Testing implementation detailsBrittle tests break on valid refactors
Skipping the RED stepNo proof the test can actually fail
Large GREEN stepsLose traceability of which test drives which code
Skipping REFACTORTechnical debt accumulates silently

Best Practices

  • Each RED-GREEN-REFACTOR cycle should take under 5 minutes
  • If GREEN requires more than 10 lines, the test is too ambitious—split it
  • Name tests as behavior specifications: test_<action>_<condition>_<outcome>
  • Run the full test suite after every REFACTOR, not just the new test
  • Commit after each complete cycle to preserve the design narrative
  • Use test doubles (mocks, stubs) only at architectural boundaries

Platform Compatibility

PlatformSupportNotes
CursorFullShell tool runs tests inline
VS CodeFullTerminal integration for test runs
WindsurfFullCascade executes test commands
Claude CodeFullDirect shell access for pytest/jest
ClineFullConfigurable test runner
aiderPartialManual test confirmation needed

Related Skills

  • Systematic Debugging - Root cause analysis that starts by writing a failing test reproducing the bug
  • Code Review - Quality gate that verifies test coverage alongside production code changes
  • Subagent-Driven Development - Isolated subagents that follow TDD cycles independently for each subtask

Keywords

tdd test-driven-development red-green-refactor failing-test-first test-first unit-testing regression-prevention atomic-commits


© 2026 googleadsagent.ai™ | Agent Skills™ | MIT License

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 3 of the 12 instructions most tdd skills give in ~1.2k tokens

Counted across 594 of the 695 authors here whose files we hold, read 2026-09-06

  • Write minimal code to pass the testhere, and in 356 of 594, across 332 files
  • Write a failing test before writing production codehere, and in 240 of 594, across 221 files
  • Refactor code only after tests passin 184 of 594, across 169 files
  • Refactor code while keeping tests greenin 140 of 594, across 133 files
  • Verify the test fails for the expected reasonin 133 of 594, across 121 files
  • Run tests after each refactor stepin 108 of 594, across 102 files
  • Use real code instead of mocks whenever possiblein 97 of 594, across 85 files
  • Reproduce bugs with a failing test before fixingin 90 of 594, across 81 files
  • Write tests before implementing codein 88 of 594, across 70 files
  • Verify the test passes after writing codein 71 of 594, across 61 files
  • Write one test for one behaviorin 71 of 594, across 63 files
  • Run the full test suitehere, and in 63 of 594, across 56 files

Said here and by no other author read

  • Create an atomic commit after each cycle

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.