TDD就像锻炼

我们都知道，锻炼对我们有益，属于智人（Homo Sapiens Sitonourasses）物种。 但是我们大多数人做得还不够。 测试驱动开发 （TDD）也是如此。 但是相似性并不仅限于此。

通过定期锻炼，您可以锻炼肌肉。 但是，这种工作方式不是线性的。 它遵循一个向上的锯齿模式：首先破坏肌肉（ 训练 ），然后恢复（ 恢复 ），并最终变得比以前更强壮（ 超 补偿 ），然后再次破坏它们，等等：

TDD也遵循“损伤-恢复-生长”周期 。

首先，我们通过编写失败的测试来破坏系统。 因为我们的测试套件就这么说了，所以我们可以高兴地知道一切，现在，我们必须承认我们的代码仍然存在问题。 对于某些人来说，这种认识可能会对他们锻炼后的酸痛造成最大的伤害。

幸运的是，我们仅编写使测试通过所需的最少代码即可快速修复系统。 在几分钟甚至几秒钟内一切恢复绿色，我们完全有权利再次感觉良好。 TDD非常适合短时间跨度。

最后，我们通过改进设计来扩展系统。 该系统现在可以处理我们曾经扔给它的所有东西，以及更多，因为我们对概念进行了概括并在代码中给予了适当的位置。

在TDD中，破坏和恢复发生在两个级别上。

首先是句法层面。 您编写了一个调用尚不存在的代码的测试，因此该代码甚至无法编译。 接下来的修复方法是使代码编译，即使它尚未通过测试。

只有在语法恢复之后，您才可以更改代码以通过测试。 后者更多是一种语义上的治疗。

句法恢复与语义恢复之间的区别对我们的工作方式具有影响。

可以用多种方法来破坏程序的语法，并且在许多情况下，足够复杂的IDE可以帮助其修复。 例如，当您编写一个引用尚不存在的类的测试时，Eclipse提供了一个快速修复程序来为您创建该类。

另一方面，语义修复更加困难。 转换优先级前提的转换可以看作是标准的构建基块，并且至少其中一些可以自动化。 但这距离IDE生成使失败的测试通过的代码还有很长的路要走。

我还没有看到许多TDD练习者做过等同于在海滩上散步以炫耀坚硬的腹肌的运动，这可能是一件好事。

但是就像我们欣赏一个坚强，肌肉发达的朋友在帮助我们移动时如何轻松搬运任何家具一样，产品所有者也喜欢这样，我们可以在很短的时间内提供任何功能。

不幸的是，它只是没有给我们任何日期评分。 为此，我们确实需要上体育馆。

翻译自: https://www.javacodegeeks.com/2018/01/tdd-like-working.html