Skills Guide

Test-Driven Development

VerifiedSafe

Rigid RED → GREEN → REFACTOR cycle. Write a failing test before any implementation.

Download and use
Sby Skills Guide Bot
TestingIntermediate
7/28/2026
Claude CodeCursorWindsurfCopilotCodex
#tdd#red-green-refactor#unit-testing#test-first#refactoring

Recommended for

Claude CodeTest generationCursorCopilotRefactoringWindsurf

Automated summary

This skill enforces a strict TDD cycle — red, green, refactor — for any new feature, bug fix, or refactoring.

Strengths

  • Explicitly requires a failing test before any implementation is written.
  • Breaks work into small, clearly named units of testable behavior.
  • Guards against regressions by requiring a green suite after every change.
  • Separates refactoring from behavior changes, with no new logic added during cleanup.

Limitations

  • Does not cover integration, end-to-end, or performance testing.
  • Can slow down exploratory spikes, prototypes, or throwaway code.
  • Assumes the agent can run tests and correctly interpret failures.
When to use it

Use it when building or fixing production code where automated tests exist and regression prevention matters.

When not to use it

Avoid it for exploratory spikes, throwaway prototypes, or environments where tests cannot be executed.

Security analysis

Safe
Quality score92/100

The skill is a pure TDD methodology guide with no tool declarations, commands, network access, file operations, or secrets handling. It cannot cause execution risk as written.

No concerns found

How this analysis is made

Examples

New function with TDD
Use the Test-Driven Development skill to add a `calculateTotal` function to `src/cart.js`. Start with a failing test for an empty cart, then implement only enough code to pass, and refactor before adding the next behavior.
Bug fix with reproduction test
Fix the bug where `formatDate` returns an invalid string for leap days. First write a failing unit test that reproduces the issue, then make it pass with the smallest change, and run the full test suite.
Refactor under green tests
Refactor the `useTransactions` hook to remove duplicated filtering logic. Keep the existing test suite green after every change and do not add new behavior without a new failing test.

Skill: Test-Driven Development

Trigger

Load this skill whenever:

  • Writing a new function, hook, component, or module
  • Fixing a bug (the bug must have a test that reproduces it before the fix)
  • Refactoring existing code
  • Adding a new API endpoint or store action

Type

Rigid — The RED → GREEN → REFACTOR cycle is non-negotiable. Never write implementation code before a failing test exists.

Instructions

Phase 1 — RED (Write a failing test)

  1. Identify the smallest possible unit of behavior to implement.
  2. Write a test that describes the expected behavior. The test must:
    • Have a descriptive name (it('returns zero when no transactions exist', ...))
    • Test one thing only
    • Currently fail (you have not written the implementation yet)
  3. Run the test. Confirm it fails with the expected error, not an import error or syntax error.
  4. Do not proceed to Phase 2 until the test fails for the right reason.

Phase 2 — GREEN (Make the test pass with minimal code)

  1. Write the simplest possible implementation that makes the test pass.
  2. Do not add logic the test does not require. Resist the urge to generalize.
  3. Run the test. Confirm it passes.
  4. Do not proceed to Phase 3 if any other tests are broken.

Phase 3 — REFACTOR (Clean up without changing behavior)

  1. Improve the implementation: extract duplication, rename variables, simplify logic.
  2. Run the full test suite after every change. All tests must stay green.
  3. Do not add new behavior during refactor. If you think of something new, write a new test first (return to Phase 1).

Repeating the cycle

  1. For each additional behavior, return to Phase 1. One cycle per behavior unit.

Verification

  • A failing test exists before any implementation is written.
  • The test name describes behavior, not implementation details.
  • After GREEN, no other tests are broken.
  • After REFACTOR, the test suite is fully green and the code is cleaner than before.
  • At no point was implementation written without a corresponding test.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/test-driven-development-ms47vpy5/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/test-driven-development-ms47vpy5' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/test-driven-development-ms47vpy5/download' --output '.skill-downloads/test-driven-development-ms47vpy5/SKILL.md.part' && mv '.skill-downloads/test-driven-development-ms47vpy5/SKILL.md.part' '.skill-downloads/test-driven-development-ms47vpy5/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/test-driven-development-ms47vpy5/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills

ClickHouse Performance Comparison

Testing

Evaluate ClickHouse performance test results, check PR performance changes, compare with history, and assess whether a result is actionable.

Claude CodeintermediateSafe 49,547
Skills Guide Bot

Analyze CI Performance Reports

Testing

Analyze CI performance comparison reports for a ClickHouse PR. Cross-references master history to distinguish real regressions from flaky tests.

Claude CodeintermediateSafe 49,516
Skills Guide Bot

Santa Method

Testing

Multi-agent adversarial verification with two independent reviewers. Output is checked twice and iteratively fixed until both pass before shipping.

Claude CodeCodexCursorintermediateSafe 244,766
Skills Guide Bot