练习TDD时的指导原则是什么？

Question

这应该是一个悬而未决的问题，但我希望答案更多地关注代码设计方面。

帮助缩小范围：

• 如果一个类应该是一个具体的类或一个被嘲笑的接口，当它不是那么明显时，你如何判断。
• 您在分配角色和职责方面的经验是什么。
• 您通常会选择哪种依赖深度。
• 已经感知到的目标设计有多少会影响到tdd过程。
• 使用tdd驱动的实现符合预先存在的代码的经验是什么？
• 任何其他设计考虑因素。

谢谢！

Answer 1

叔叔鲍勃定义the three laws of TDD：

• 除非要通过失败的单元测试，否则不允许编写任何生产代码。
• 您不得再编写任何单元测试，而不是足以使其失败;编译失败就是失败。
• 您不能再编写足以通过一次失败的单元测试的生产代码。

遵循经典的Red-Green-Refactor循环，请记住the four rules of simple design defined by Kent Beck。在重构阶段应用它们。代码必须（按优先顺序）：

• 运行所有测试
• 不包含重复的代码
• 表达作者想要表达的所有想法
• 最小化类和方法

Answer 2

TDD的第0条法则：

在繁琐的时候打破TDD流程motherfucker！

你怎么知道TDD太繁琐了？当你经常写测试时 5分钟，它突然带你超过8小时轮班写 那个部分的测试，称第三方的东西，然后它也是 乏味。忘记单元测试并不时手动测试。目标 是有95％被覆盖，而不是100％。