TDD误区

当我处理有关测试驱动开发（TDD）的上一篇文章时 ，我读了许多关于该主题的博客文章和几本书，发现我不同意其中的一些。 甚至一些非常重要的。 似乎大多数软件专家只是误解了软件开发的工作方式。 也许是因为他们并不是真正的程序员，而是书的作者和会议发言人。

罗伯特·马丁（ @unclebobmartin ）在TDD的周期中 ：

如果您根据测试对生产代码进行的更改使该测试通过，但没有使其他未编写的测试通过，则您可能会使生产代码过于具体。

我不同意。 这种说法与测试的哲学背道而驰：“通过测试是弱测试。” 不幸的是，对测试的传统理解恰恰相反： 必须通过测试才能使我们高兴。 因此，如果我们一直在考虑如何使我们的未来测试通过，那么我们将不知所措：测试将通过，代码质量将下降。 相反，我们必须以一种易于在将来的测试中打破的方式设计代码。 该代码必须帮助其测试将其破坏！ 因为容易产生“红色”的测试是一个很好的测试。 始终为“绿色”的测试是无用的测试。 鲍勃叔叔，我敢肯定，知道这一点。

《 红绿重构》 （2005年11月）中的James Shore（ @jamesshore ）：

您将很快地经历几个周期，然后发现自己放慢了速度，并花了更多时间进行重构。

我不同意。 我对前两个步骤没有什么要求：1）测试未通过，因此测试为“红色”； 2）代码固定并通过后，测试为“绿色”。 我不同意重构是修复测试的人的责任。 如果代码需要重构，那就是一个bug ，就像其他任何bug一样，无论是功能上的还是设计上的。 必须对其进行报告，分配和付款。 如果我们的意图不是必需的并且已为之付费，我们就不得对其进行任何代码修改。 修复测试后进行重构是对项目中管理和协调结构的轻率违反。

罗伯特·马丁（ @unclebobmartin ）在《 TDD不起作用》 （2014年4月）中：

您不必为测试双打编写测试，因为实际的单元测试和生产代码就是这些代码段的测试。

我不同意。 测试双打（也称为假对象 ）是可以帮助我们查找代码损坏位置的工具。 如果该工具不可靠，我们如何针对它测试代码？ 这让我想起了一个古老的笑话，病人来找医生，说：“帮助我，医生，我用手指触摸它的任何地方，身体都会受伤！”，医生回答“这只是你的手指-断了！” 这里发生一种非常相似的情况：如果我们用损坏的“测试双打”测试生产对象，则它们看起来都将损坏。

像TSA一样在测试中的 David Heinemeier Hansson（ @dhh ）（2012年4月）：

高于1：2的代码测试比率是一种气味，高于1：3的则是臭味。

我不同意。 我不知道使用什么度量单位来比较“代码”和“测试”，但我只能假设代码行。 我很好奇，并决定在我的一些项目中计算该比率。 首先，我尝试了不可变的GitHub Java API客户端jcabi-github 。 这些数字是：生产类中的9.8K LoC，内置假类中的6.2K，测试类中的16.2K。 因此，该比率为9.8至22.4，这意味着1：2.3。 大卫说，介于“气味”和“臭味”之间。 然后，我计算了我的其他一些项目的比率： jcabi-http （1：1）， xembly （1：0.92）， takes （1：0.91）和rultor （1：0.6）。 比率越高，我对产品质量的信心就越高。 因此，我不认为这是气味或臭味。 相反，在具有香味的产品中，测试代码的数量是其生产同类产品的几倍。

Kent Beck（ @kentbeck ）中的单元测试有多深？ （2008年9月）：

我收到的代码有效，而不是测试代码。

我不同意。 测试不是单独的产品，无论我们是否付费。 测试是代码的一部分。 开发，维护和验证的工具。 测试类似于文件名。 我们不会编写代码来命名所有文件1.java ， 2.java ， 234.java ，然后说：“现在您付钱给我，以便我可以对其进行正确的重命名。” 那会很奇怪，对吧？ 这就是“我因编写测试而没有报酬”的说法对我来说的感觉：很奇怪。 我们是否真的需要付费才能正确命名文件？ 我们只是这样做，因为它对我们很方便。 因为适当的自我描述文件名使我们的代码更具可读性和可维护性。 不可能想象没有测试的现代可维护代码库。 我实际上建议将这一短语更改为：“我从经过测试的代码中获得报酬，而不仅仅是获得代码。”

我将继续更新这篇文章。 如果您知道有关TDD的“好”文章，请发送给我 ； 也许我会发现一些有趣的东西。

翻译自: https://www.javacodegeeks.com/2019/07/tdd-misbeliefs.html