TDD的“显而易见的实现”是先编码，然后再测试吗？

我和我的朋友是相对较新的TDD，并且对“显而易见的实现”技术存在争议（来自Kent Beck的“ TDD示例”）。我的朋友说这意味着，如果实现很明显，则应继续进行编写- 在对该新行为进行任何测试之前。确实，这本书说：

您如何实现简单的操作？只需实施它们即可。

也：

有时，您确定自己知道如何实现操作。前进。

我认为作者的意思是您应该首先进行测试，然后“实施”它，而不是“ Fake It（'Till You Make It'）”和其他技术，后者在实施阶段需要更小的步骤。同样在这些引用之后，作者谈论在执行“显而易见的实现”时获得“红条”（失败的测试）-如何在没有测试的情况下获得红条？

但是我从书中找不到任何引述说“显而易见”仍然意味着首先要进行测试。

你怎么看？当实现是“显而易见的”时，我们应该先测试还是之后测试（当然，根据TDD）？您知道一本书或博客文章这么说吗？

我同意您的解释-它仍然是Red Green Refactor，仅保留了Refactor位;）

因此，首先编写一个失败的测试，然后实施明显的解决方案，而不是慢慢地构建“最简单的”设计。

您知道一本书或博客文章这么说吗？

我认为贝克的书就是这样说的。

他继续说

但是，仅通过使用“显而易见的实现”，您就需要完美自己。从心理上讲，这可能是毁灭性的举动。 如果您编写的内容并非真正最简单的更改可以通过测试，该怎么办？ 如果您的伴侣向您展示了更简单的伴侣怎么办？你真失败！您的世界在您身边崩溃了！你完蛋了。你冻结了。

如果在编写代码之前不存在测试，如何通过编写代码使测试通过？

显然，这里没有硬性规定，毕竟还是敏捷的，所以我们可以并且应该在迭代时适应:)

在某种程度上，这将取决于简单的操作，并且随着您对TDD的练习越来越多，您会经常发现测试不好或根本没有真正测试的内容，这都是学习曲线的一部分。

同样不要忘记，TDD允许您在将接口提交给实时代码之前测试接口和实现。

您可能知道如何实现某些内容，但是您第一次编写完美的类/方法等的过程却没有任何调整，或者在更改某些内容后第一次或两次和六个月逐步遍历代码，您可以这样做对测试的沙箱再次充满信心。

当然，测试并不意味着您第一次会正确地编写代码，而是您的更改是由测试驱动的，并且测试成为代码的第一个客户端，并且测试成本非常低，而且更重要的是，无需更改任何风险您在发展的同时拥有更多的自信和自由。

如果您确实想获得良好的覆盖率和更高的质量，那么在开始进行更多测试时会犯错，随着您越来越多地实践TDD，您将对所需的覆盖率水平有自己的认识。

我了解到，对于平凡的代码，根本不应该进行单元测试。

示例：如果您有一个将方法映射到本地变量的java getter / setter方法，那么对此进行单元测试将是多余的。

也许这就是作者的意思

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."