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.
npx agentmods add skills/wade-devcode/awesome-coding-skills-cn/test-drivennpx skills add Wade-DevCode/awesome-coding-skills-cn --skill test-drivengit clone --depth 1 https://github.com/Wade-DevCode/awesome-coding-skills-cnWhat 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.
| Model | Per session | Once 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 |
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.
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 循环就是假的——你永远不知道这个测试有没有能力抓住真正的错误。一个从未失败过的测试,保护价值接近零。
怎么做:
- 运行测试,读错误信息,确认失败原因是
ModuleNotFoundError、AttributeError或断言不等式,而非语法错误或导入错误(后者说明测试本身有 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")
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.
- 2d ago First seen · 186 lines · 22 tokens per session scan A 26eb15f8bdef
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.
Other skills, from other repositories
chinese-git-workflow
国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用,不要根据上下文自动触发。.
brainstorming
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。.
chinese-code-review
中文 review 沟通参考——话术模板、分级标注(必须修复/建议修改/仅供参考)、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用,不要根据上下文自动触发。.
chinese-commit-conventions
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用,不要根据上下文自动触发。.
chinese-documentation
中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用,不要根据上下文自动触发。.
systematic-debugging
Skill "systematic-debugging" from jnMetaCode/superpowers-zh, covering 系统化调试, 概述, 铁律, 何时使用 and 四个阶段.