协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
test-driven-development【开发与工程】实现任何功能或修复 bug 时,写实现代码之前必须使用。铁律:没有先看到失败的测试,就没有生产代码。触发词:写代码、实现功能、修bug、TDD、写测试。
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
先写测试,看它失败,写最少代码让它通过。
如果你没看到测试失败,你就不知道它是否测试了正确的东西。
没有先看到失败的测试 = 没有生产代码
先写代码再写测试?删掉,重新来。
永远:
例外(需要人类伙伴确认):
"就这一次跳过 TDD 吧"?停。那是合理化借口。
写一个最小测试展示应该发生什么。
好的测试:
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
清晰命名,测试真实行为,只测一件事
差的测试:
def test_retry():
mock = Mock(side_effect=[Exception, Exception, "success"])
retry(mock)
assert mock.call_count == 3
模糊命名,测 mock 不是测代码
要求:
强制步骤,不可跳过。
pytest tests/path/test.py::test_name -v
确认:
测试直接通过? 你在测已有行为,修正测试。
写最简单的代码让测试通过。不要:
强制步骤。
pytest tests/path/test.py::test_name -v
确认:
只在绿色之后:
保持测试绿色,不要添加行为。
下一个失败测试 → 下一个功能。
| 品质 | 好的 | 差的 |
|---|---|---|
| 最小 | 一件事。名字里有"和"?拆开。 | test_validates_email_and_domain() |
| 清晰 | 名字描述行为 | test1、test_works |
| 展示意图 | 展示期望的 API | 隐藏代码应该做什么 |
"我先写代码再补测试来验证"
事后写的测试立刻通过。立刻通过什么也证明不了:
| 借口 | 现实 |
|---|---|
| "太简单不用测" | 简单代码也会坏。写测试只花 30 秒。 |
| "我稍后补测试" | 测试立即通过证明不了任何事。 |
| "我已经手动测过了" | 临时的 ≠ 系统性的。没有记录,无法重跑。 |
| "删掉 X 小时工作太浪费" | 沉没成本谬误。保留未验证代码 = 技术债。 |
| "TDD 太死板,实际点" | TDD 就是实际的:提交前找到 bug(比事后调试快)。 |
| "保留做参考,先写测试" | 你会改编它。那就是测试后补。删除就是删除。 |
以下任何情况出现,意味着跳过 TDD:
以上全部意味着:删代码,用 TDD 重来。
完成前检查: