这应该是一个悬而未决的问题，但我希望答案更多地关注代码设计方面。
为了帮助缩小答案的范围：
- 当一个类不那么明显时，你如何决定一个类应该是一个具体的类还是一个被模拟的接口。
- 你在分配角色和职责方面有什么经验。
- 您通常会达到什么依赖深度。
- 已经感知到的目标设计有多少会影响 tdd 过程。
- 使 tdd 驱动的实现适合预先存在的代码的经验是什么？
- 任何其他设计考虑。
谢谢！
问问题
218 次
2 回答
3
鲍勃大叔定义了 TDD 的三个定律：
- 除非是为了通过失败的单元测试，否则您不得编写任何生产代码。
- 不允许您编写任何足以导致失败的单元测试；编译失败就是失败。
- 不允许您编写任何超过足以通过一个失败的单元测试的生产代码。
遵循经典的 Red-Green-Refactor 循环，请记住Kent Beck 定义的简单设计的四个规则。在重构阶段应用它们。代码必须（按优先顺序）：
- 运行所有测试
- 不包含重复代码
- 表达作者想要表达的所有想法
- 最小化类和方法
于 2013-11-03T13:35:06.013 回答
-1
TDD 的第 0 条定律：
太繁琐的时候就打破TDD流程，混蛋！
你怎么知道TDD太繁琐了？当您定期在 5 分钟内编写测试时，突然间要花 8 个多小时轮班来为该部分编写这些测试，这称为 3rd 方，那太乏味了。忘记单元测试并不时手动测试它。目标是覆盖 95%，而不是 100%。
于 2013-11-03T18:11:10.440 回答