对于肯特·贝克的“测试&提交-还原”(TCR)，你会跳过“红色”“红色”、“绿色”、“重构”吗？

Question

如果您还没有听说过肯特贝克(肯特贝克) TCR，那么可以这样总结:每当您的测试变成绿色时，您就提交；每当您的测试变成红色时，您就会使用git reset --hard。

这篇文章是关于如何正确地实施TCR。这与TCR的优点或缺陷无关(尽管这将是另一篇文章感兴趣的话题)。

在TDD中，您从失败的测试开始，让它们通过，然后重构。我知道TCR != TDD，但我要用TDD术语来回答我的问题：

我不知道TCR是“绿色，重构”，还是“红色，绿色，重构”。文章中并没有明确说明这一点。

很多时候，我经历过一些情况，我的测试是从绿色开始的，因为我把测试写错了，所以我总是喜欢从红色测试开始--为了给我信心，我在测试我真正认为自己是什么。

TCR看起来很吸引人，我想试一试，但我想确保我真的在尝试它，而不是我无意中创造的一些私生子。那么，当我练习TCR的时候，我应该先从失败的测试开始吗？

Answer 1

肯特贝克实际上回答了这个问题，如果你看他教TCR的录像。答案是肯定的。当你练习TCR时，你确实跳过了“红色”。

我还发现了这篇文章，它直接说明您在练习TCR时跳过红色、绿色、重构的“红色”。这个TCR工具只能在这种假设下使用。

我认为这篇文章是清楚而简洁的。下面是两张有用的图片：

TDD

TCR

Answer 2

以下只是我的一些想法，没有事实或“真相”，所以拿你认为有价值的东西，而忽略其他的。:-)

当我遇到一种新的“方法论”时，我的第一个问题是“它试图解决什么问题？”

当TDD专注于执行稳定的代码时，大多数人只记得“红色、绿色、重构”规则。是的，这是TDD的心脏。但我遇到的很多开发人员都遇到了很大的问题，使得开发周期变得非常小。这意味着将增量分割成非常小的块。

因此，他们经常编写测试，编写生产性代码，测试仍然失败，代码被更改，更改和更改，直到测试最终变成绿色。

这使得生成的代码包含不必要的元素非常有可能，因为它们是在前一次尝试中遗留下来的。现在，我们只能希望，在重构阶段，这些元素将被消除。因此，第一个重构阶段必须专注于简单的清理，而不是优化设计。而且，很多时候，经过简单的清理后，一些开发人员认为“我已经完成了重构，我已经完成了”。

由于不“允许”产生红色测试的生产性代码，这个问题得到了某种程度的解决。现在这个程序看起来如下：

• 我的代码处于绿色状态
• 我正在编写一个新的测试(可能是错误的)，=>应该会导致一个危险信号。
• 我正在编写生产代码(这也可能是错误的)。
• 我做了测试，至少有一次失败了。
• 我分析了这个问题(可能是新测试错了，新的生产代码不适合测试，或者对生产代码的更改破坏了现有的测试)。
• 有了新的知识，我重新设置代码，然后再试一次。
• 冲洗并重复，直到所有测试都是绿色的。

就我个人而言，我希望在我的TCR版本中有一个红色测试结果。在我编写测试之后，在我开始实现生产性代码之前。这个危险的信号给了我安全感，我的新测试没有实现一个“将永远是绿色”的错误。所以，我接受这个“红色”。但是，在我开始实现生产性代码之后，"red“结果(大部分见后面的内容)会导致代码重置。

当我想要遵循这个方法时，我必须学会使我的增量非常小。为下一个增量编写测试和相应的生产性代码，可能不会花费更长的时间，而只是几分钟。如果需要更长的时间，“重置”将消除大量的工作。

遵循TDD是一种API第一方法(测试使用的生产性代码的API )，并对代码设计进行深入思考。另外，遵循TCR可以加强小增量的习惯。

但也许最后的几句话。TCR是一种方法论，与TDD一样，在任何情况下都遵循它是不明智的。如果我的测试失败了，因为我犯了一个拼写错误，那么我会纠正那个拼写错误，而不是恢复，然后继续。TCR的目标是在代码工作之前不要修补代码，因为结果很可能不会像它可能的那样干净。这意味着如果我的“补丁”非常小，而且我可以完全监督它，那么我就不会重置我的代码。

请记住，TCR将导致“非常小的增量”。现在想一想“非常小的增量”中的“外显小块”，这意味着我们实际上是在谈论拼写错误的大小。

编辑: Kent在结合“测试遗留代码”时提到了这个方法。这意味着生产性代码已经存在，我们刚刚向它添加了测试。

在这种情况下，新的测试从一开始就应该是绿色的。再一次，就我个人而言，我会努力确保测试没有错误(总是绿色的)，因此，在测试运行为绿色之后，我已经完成了更改，如果测试失败，我会以某种方式更改测试。请不要添加"expect(1 === 2)“之类的内容，而是稍微更改预期的结果，比如从expect(result === "Hallo World")到expect(result === "Hallo")。

此外，肯特贝克使用了一种自动恢复方法。当测试失败时，代码将自动恢复。如果您只编写测试(而不更改生产代码)，并且测试非常小，那么这样做很好，这样错误就只能是错误的预期(期望产生代码的结果不同)。一旦其他事情可能出了问题。测试本身或更改的生产性代码，这种方法将立即删除分析问题的机会。因此，在这种情况下，我本人不会使用自动方法。

Answer 3

当我希望自己变得更加自律时，我发现自己有着同样的限制:不允许TCR中的“红色”(红色)-绿色-重构(Refactor)，这使得“观察者”(我喜欢的)变得非常困难。因此，在尝试正规化的同时，稍微调整了一下建议：

如果发生故障，请还原除测试文件之外的所有内容。

我甚至不建议使用这个插件，而是演示如何使用“观察者”https://github.com/lenntt/tcr-jest-watch-plugin来操作它。