测试驱动开发 测试前移_测试驱动开发–您做错了！

测试驱动开发 测试前移

测试驱动开发是其中一种没有得到应有的广泛应用的技术。 我知道很多开发人员都同意它带来的好处。 但是，当被问及如何实践TDD时，同一位开发人员回答：“这对我不起作用”。

当我试图理解此声明背后的“原因”时，他们开始努力寻找解释。 他们说他们只添加简单的功能。 他们说他们的申请并不那么复杂。 他们没有时间。 他们中的许多人都尝试过，但是“太浪费时间”，花费了太多的精力。

我与其中一些配对。 我有几次与他们进行了长时间的交谈，以了解他们的工作方式？ 什么地方出了错？ 结论如何？ 在许多情况下，问题出在根本上–他们只是试图将TDD应用于每个新创建的对象。

根据我的经验，我可以说这是开发人员最常见的错误。 有什么不好的呢？ 这个错误导致他们完全放弃TDD。

简而言之，TDD

测试驱动开发是一种设计技术。 使用它时，您将不会解决不存在的问题，不会添加无用的代码，而是将编写易于使用和理解的代码。

TDD的实质可分为三个步骤：

• 红色–编写失败的测试方案。
• 绿色–添加足够（但不更多）代码以满足新要求。
• 重构–提高书面代码的质量。 在生产和测试方面。

如果您想了解有关TDD的更多信息，可以从此处 ， 此处和此处开始 。

错误看起来像什么？

我们从第一个周期开始。

• 红色–我们添加了新的测试场景（必须编译代码）：

• 绿色–我们正在添加代码以满足新添加的测试的要求：

• REFACTOR-我们改进了代码和测试。

到目前为止，一切都很好。 让我们添加另一个场景：

• 红：

• 绿色：

• 参考：

这就是许多开发人员停止进一步开发System Under Tests（SUT）的时刻。 他们开始为两个新创建的类添加测试。 不仅如此，他们还尝试以TDD方式做到这一点。

这两个错误导致许多人放弃了TDD。 他们开始认为这项技术花费了他们太多的时间和精力，如果…TDD以这种方式工作，我什至会同意。

有什么问题和为什么有问题？

明确地说，这不是测试驱动开发的工作方式。

让我解释一下原因：

• SUT开发是您必须支持的方案的来源。 这就是您首先编写代码的原因。 如果在完全编写SUT功能之前跳入其他类的测试，则您可能会想向那里添加（仅对那些类有用）以后才有用的功能。
• SUT开发速度较慢–您必须为每个依赖项添加测试。 您必须暂停当前的开发并切换上下文。
• 在完成SUT开发之前，您需要执行许多重构步骤。 当前的设计可能会改变很多次。 您有机会摆脱已经创建的类。 如果在重构步骤中以TDD方式针对每个SUT依赖关系编写测试，则将开始将TDD视为浪费时间。
  直到您还没有完成设计，否则它可能会更改。 如果发生这种情况，所有测试和您的努力都将被丢弃。

如何做得更好？

• 专注于SUT开发–这就是为什么您首先编写此代码的原因。
• 不要将时间浪费在完善可能会改变的依赖上。
• 不要将时间浪费在添加下一个SUT测试方案之后可能消失的测试依赖项上。
• 在完成SUT开发之前，请记住–重构后的下一步，添加新的失败方案。

您应该怎么做而不是为新创建的依赖项编写测试？ 只需回到TDD，并在重构后移至RED步骤即可：

使用TDD并不意味着您必须对所有内容进行TDD

TDD是一种设计技术。 它可以帮助您建立良好的设计并避免产生无用的代码。

TDD不是测试技术。 这意味着一旦开始使用它，则不必以这种方式添加以后编写的每个测试用例。

即使完成了SUT开发，您也可能不得不编写更多没有TDD的测试：

• 您将必须测试您的依赖关系。 是的，也许有充分的理由以TDD方式添加几个新测试以抛光其形状，但是并非总是如此。 但是，您将不得不涵盖在SUT开发过程中已经产生的现有功能。
• 一旦建立了SUT设计，您将无法添加任何新的失败测试，​​这并不总是意味着您已经完成了测试。 这只是意味着您已经完成了TDD。
  有时，有充分的理由添加更多复杂的测试用例只是为了仔细检查功能是否确实要您想要。

我希望本文能帮助您了解如何正确地遵循TDD步骤，其中TDD没有任何意义，而TDD已经结束的事实并不意味着测试已经完成。

如果您还有其他疑问，请随时在文章下方分享评论。

翻译自: https://www.javacodegeeks.com/2019/01/test-driven-development-wrong.html

测试驱动开发 测试前移