test-driven

A test-driven development guide. TDD means writing a test for the desired behaviour first, seeing it fail, then writing the smallest implementation that makes it pass.

In plain words
What is it for?
Use it when adding features, creating interfaces, fixing bugs, or changing existing code. It guides the red-fail, minimal implementation, green-pass cycle and protects existing tests.
Why use it?
It helps prevent tests from merely confirming how code was already written and makes the expected behaviour clear before implementation begins. It also provides a safety net for bug fixes and refactoring.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/wade-devcode/awesome-coding-skills-cn/test-driven
Any agent
npx skills add Wade-DevCode/awesome-coding-skills-cn --skill test-driven
Clone the repo
git clone --depth 1 https://github.com/Wade-DevCode/awesome-coding-skills-cn

Made for: Claude Code, Codex.

Per session 22 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,036 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00022 $0.02036
Opus 5 $0.00011 $0.01018
Sonnet 5 $0.00004 $0.00407
Haiku 4.5 $0.00002 $0.00204

Measured 2d ago against content hash 26eb15f8bdef, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

test-driven scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/test-driven/SKILL.md · 186 lines

How it starts

The opening of the file, as written. The whole thing — 186 lines — stays where its author put it; the contents beside it link to each section on GitHub.

测试驱动

何时用

  • 实现一个新功能或新接口,还没有一行实现代码时。
  • 修复 bug,想用测试把"错误行为"钉死,防止日后回归。
  • 重构已有代码,需要一张安全网确认行为没有改变。
  • 不确定某个边界条件下系统应该做什么,想用测试把期望行为写清楚再动手。

核心规则

1. 先写测试

规则: 在写任何实现代码之前,先写一个表达期望行为的测试。

为什么: AI 最常见的路线是"先把功能写出来,最后补测试"——但补出来的测试天然向实现靠拢,只覆盖 happy path,不会质疑假设。等实现已经存在,测试变成了橡皮图章:它测的是"代码现在怎么跑",而不是"代码应该怎么跑"。先写测试才能强迫自己想清楚"调用方视角的合约"。

怎么做:

  • 从调用方视角出发:给什么输入,期望得到什么输出或副作用?
  • 测试文件比实现文件先存在,import 指向尚不存在的模块也没关系,先写好断言。
  • 一次只写一个测试用例,专注于当前最重要的行为。

2. 看它失败

规则: 写完测试后立即运行,确认测试因"功能未实现"而失败,而非因测试本身写错而失败。

为什么: AI 写完测试后经常直接跳到实现,跳过"看红"这一步。但如果测试从一开始就是绿的(比如断言条件写反了、assert True 之类),那整个 TDD 循环就是假的——你永远不知道这个测试有没有能力抓住真正的错误。一个从未失败过的测试,保护价值接近零。

怎么做:

  • 运行测试,读错误信息,确认失败原因是 ModuleNotFoundErrorAttributeError 或断言不等式,而非语法错误或导入错误(后者说明测试本身有 bug)。
  • 如果测试意外通过了,停下来审查:是断言写错了,还是功能早已存在?搞清楚再继续。
  • 把失败信息记下来,待会儿用于确认"绿"时对应的正是这个失败点。

3. 最小实现

规则: 只写刚好让当前测试通过的代码,不多写。

为什么: AI 一旦开始实现就容易"发散":顺手加错误处理、抽接口、加日志、考虑将来的扩展——测试还没绿,代码已经膨胀了一倍。最小实现原则把"让这一个测试通过"和"完善代码"拆成两个独立步骤,避免在不确定行为是否正确的时候就堆代码。

怎么做:

  • 允许暂时写"硬编码返回值"——目的是让测试绿,再靠下一个测试逼迫你写真正的逻辑。
  • 克制"顺手做"的冲动:看到相关代码有坏味道,记到 TODO,当前步骤只做让测试通过的最小改动。
  • 实现完成后立即运行测试,不要先重构再运行。

4. 看它通过

规则: 运行测试,确认当前测试由红变绿,且原有测试仍然全绿。

为什么: AI 改完代码后会说"应该好了"而不真的跑。或者只运行新测试,没跑全量套件——导致刚写的实现破坏了其他已有功能,而这个问题要等 CI 才暴露。本地绿才算绿,口头绿不算绿。

怎么做:

  • 运行全量测试套件,不只跑新写的测试文件。
  • 若出现意外的新失败,先查清楚是新代码引入的回归还是测试本身的问题,再继续。
  • 全绿之后才可以进入重构阶段("整理代码")。

5. 测行为,不测实现

规则: 测试只断言对外可观察的行为(返回值、副作用、抛出的异常),不断言内部实现细节(私有方法是否被调用、内部变量的值、调用次数等)。

为什么: AI 写测试时有一个典型错误:用 mock.assert_called_once_with(...) 检查内部函数调用顺序,或者 spy 私有方法——这样的测试与实现高度耦合。一旦重构内部逻辑(即便行为没有任何改变),测试就会莫名其妙地挂掉,让人觉得"测试在妨碍重构"而最终把它删掉。测试应该是安全网,不应该是紧身衣。

怎么做:

  • 断言函数的返回值,而不是函数内部调用了哪个子函数。
  • 断言系统的状态变化(数据库里有没有记录、文件是否存在),而不是某个私有方法被调用了几次。
  • Mock 只用于隔离真正的外部依赖(网络、数据库、时钟),不用于验证内部调用链。

正例 / 反例

完整红→绿循环示例(Python + pytest)

场景: 实现一个 parse_amount 函数,接受形如 "¥1,234.56" 的字符串,返回浮点数 1234.56;若格式非法则抛出 ValueError


第一步:先写测试(此时 parse_amount 函数根本不存在)

# tests/test_parse_amount.py
import pytest
from myapp.currency import parse_amount   # 模块尚不存在,先写断言

def test_parse_valid_amount():
    assert parse_amount("¥1,234.56") == 1234.56

def test_parse_without_symbol():
    assert parse_amount("1,234.56") == 1234.56

def test_parse_invalid_raises():
    with pytest.raises(ValueError):
        parse_amount("not_a_number")

Read the full file on GitHub · 186 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 186 lines · 22 tokens per session scan A 26eb15f8bdef

Subscribe to this mod's changes

test-driven is a skill published in the GitHub repository Wade-DevCode/awesome-coding-skills-cn (6 stars, last pushed 2mo ago), licensed MIT. It adds 22 tokens to every session and 2,036 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

chinese-git-workflow

国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用,不要根据上下文自动触发。.

jnMetaCode/superpowers-zh · 69 tokens

brainstorming

在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。.

jnMetaCode/superpowers-zh · 40 tokens

chinese-code-review

中文 review 沟通参考——话术模板、分级标注(必须修复/建议修改/仅供参考)、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用,不要根据上下文自动触发。.

jnMetaCode/superpowers-zh · 62 tokens

chinese-commit-conventions

中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用,不要根据上下文自动触发。.

jnMetaCode/superpowers-zh · 65 tokens

chinese-documentation

中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用,不要根据上下文自动触发。.

jnMetaCode/superpowers-zh · 62 tokens

systematic-debugging

Skill "systematic-debugging" from jnMetaCode/superpowers-zh, covering 系统化调试, 概述, 铁律, 何时使用 and 四个阶段.

jnMetaCode/superpowers-zh · 24 tokens