Programming · Testing
test-driven-development
/test-driven-development
实现任何功能或修复 bug 时,写实现代码之前必须使用。铁律:没有先看到失败的测试,就没有生产代码。触发词:写代码、实现功能、修bug、TDD、写测试。
For whom
- Author
- yinqd3 ↗
- Repository
- workbuddy-skills ↗
- Licence
- MIT
- Last repository change
- 03.06.2026
Assessment and security
96/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability21 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
- Files in this package
- 1
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
Deprecation
No signals detected. Repository changed on 03.06.2026, without references to retired models or APIs.
Licence
MIT, open: use and modify while retaining author attribution.
What it does and when to use it
实现任何功能或修复 bug 时,写实现代码之前必须使用。铁律:没有先看到失败的测试,就没有生产代码。触发词:写代码、实现功能、修bug、TDD、写测试。
Original author description
实现任何功能或修复 bug 时,写实现代码之前必须使用。铁律:没有先看到失败的测试,就没有生产代码。触发词:写代码、实现功能、修bug、TDD、写测试。
How it works
- 核心原则
- 铁律
- 何时使用
- 红-绿-重构循环
- 好测试的标准
- 为什么顺序重要
- 常见借口粉碎
- 红灯 — 停,重来
- 验证清单
Original SKILL.md headings · 175 lines, 333 words
SKILL.md preview
---
name: test-driven-development
description: 实现任何功能或修复 bug 时,写实现代码之前必须使用。铁律:没有先看到失败的测试,就没有生产代码。触发词:写代码、实现功能、修bug、TDD、写测试。
agent_created: true
---
# 测试驱动开发(TDD)
## 核心原则
**先写测试,看它失败,写最少代码让它通过。**
如果你没看到测试失败,你就不知道它是否测试了正确的东西。
## 铁律
```
没有先看到失败的测试 = 没有生产代码
```
先写代码再写测试?删掉,重新来。
- 不要保留做"参考"
- 不要在写测试时"改编"它
- 不要看它
- 删除就是删除
## 何时使用
**永远:**
- 新功能
- Bug 修复
- 重构
- 行为变更
**例外(需要人类伙伴确认):**
- 一次性原型
- 自动生成的代码
- 配置文件
"就这一次跳过 TDD 吧"?停。那是合理化借口。
## 红-绿-重构循环
### RED — 写失败测试
写一个最小测试展示应该发生什么。
**好的测试:**
```python
def test_retries_failed_operations_three_times():
attempts = 0
def operation():
nonlocal attempts
attempts += 1
if attempts < 3:
raise Exception("fail")
return "success"
result = retry(operation)
assert result == "success"
assert attempts == 3
```
清晰命名,测试真实行为,只测一件事
**差的测试:**
```python
def test_retry():
mock = Mock(side_effect=[Exception, Exception, "success"])
retry(mock)
assert mock.call_count == 3
```
模糊命名,测 mock 不是测代码
**要求:**
- 一个行为一个测试
- 清晰的描述性名称
- 测试真实代码(非必要不用 mock)
### 验证 RED — 看它失败
**强制步骤,不可跳过。**
```
pytest tests/path/test.py::test_name -v
```
确认:
- 测试失败(不是报错)
- 失败信息符合预期
- 失败原因 = 功能缺失,不是拼写错误
**测试直接通过?** 你在测已有行为,修正测试。
### GREEN — 最少代码
写最简单的代码让测试通过。不要:
- 加测试不需要的选项
- 重构其他代码
- "改进"超过测试要求的范围
### 验证 GREEN — 看它通过
**强制步骤。**
```
pytest tests/path/test.py::test_name -v
```
确认:
- 目标测试通过
- 所有其他测试仍然通过
- 输出干净(无错误、无警告)
### REFACTOR — 清理
只在绿色之后:
- 消除重复
- 改进命名
- 提取辅助函数
保持测试绿色,不要添加行为。
### 重复
下一个失败测试 → 下一个功能。
## 好测试的标准
| 品质 | 好的 | 差的 |
|:---|:---|:---|
| 最小 | 一件事。名字里有"和"?拆开。 | `test_validates_email_and_domain()` |
| 清晰 | 名字描述行为 | `test1`、`test_works` |
| 展示意图 | 展示期望的 API | 隐藏代码应该做什么 |
## 为什么顺序重要
**"我先写代码再补测试来验证"**
事后写的测试立刻通过。立刻通过什么也证明不了:
- 可能测了错的东西
- 可能测了实现而非行为
- 可能漏了边界情况
- 你从来没见过它抓到 bug
## 常见借口粉碎
| 借口 | 现实 |
|:---|:---|
| "太简单不用测" | 简单代码也会坏。写测试只花 30 秒。 |
| "我稍后补测试" | 测试立即通过证明不了任何事。 |
| "我已经手动测过了" | 临时的 ≠ 系统性的。没有记录,无法重跑。 |
| "删掉 X 小时工作太浪费" | 沉没成本谬误。保留未验证代码 = 技术债。 |
| "TDD 太死板,实际点" | TDD 就是实际的:提交前找到 bug(比事后调试快)。 |
| "保留做参考,先写测试" | 你会改编它。那就是测试后补。删除就是删除。 |
## 红灯 — 停,重来
以下任何情况出现,意味着跳过 TDD:
- 测试之前写了代码
- 代码后补的测试
- 测试立即通过
- 解释不了测试为什么失败
- "我稍后加测试"
- 合理化"就这一次"
- "我已经手动测过了"
**以上全部意味着:删代码,用 TDD 重来。**
## 验证清单
完成前检查:
- [ ] 每个新函数/方法有测试
- [ ] 看到每个测试在实现前失败
- [ ] 每个测试因预期原因失败(功能缺失,不是拼写错误)
- [ ] 写了最少代码让每个测试通过
- [ ] 所有测试通过
- [ ] 输出干净
- [ ] 测试用真实代码(mock 只在不可避时)
- [ ] 覆盖边界情况和错误
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · yinqd3/workbuddy-skills | 96 | MIT |
| GanyuanRan/Aegis | 100 | MIT |
| lucasouzadev/agent-kit-skill | 100 | MIT |
| zeative/satgas | 100 | AGPL-3.0 |
| nikospavlopoulos/devops-mutant-powers | 100 | MIT |
| JohnStrunk/CommonCast | 100 | LGPL |
| Sanit-mann/The-Insectoids | 100 | MIT |
| mastro993/fstack | 100 | MIT |
| jelvodev/yaap | 100 | MIT |
Database snapshot: 13.11.2026 · package version 0854615ca70e (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 100tdd
Enforces test-driven development: write failing test, write minimal code to pass, refactor. Mandatory for all implementation work. Use when writing any production code, implementing features, fixing bugs, refactoring, or when the user says "write code", "implement", "fix this",… - 90tdd
AI DevKit · Test-driven development — write a failing test before writing production code. Use when implementing new functionality, adding behavior, or fixing bugs during active development. - 100test-driven
Test-Driven Development (TDD) across any supported language. Use when implementing features or fixes with TDD methodology, writing tests before code, or following XP-style development. - 100tdd
Test-driven development workflow. Use when the user asks to "write tests first", "TDD", "add test coverage", "test this function", or wants to develop a feature test-first. - 100behavior-driven-development
Applies behavior-driven development principles including Gherkin scenarios and test-driven development. This skill should be used when the user asks to implement features, fix bugs, or when writing executable specifications and tests before writing production code. - 100test-driven-development-codex
Enforce strict test-driven development via Codex-backed implementation. Use only when the user explicitly asks for the Codex-backed TDD workflow.