关于测试驱动开发但在反向答案

【问题标题】：On Test Driven Development BUT in REVERSE关于测试驱动开发但在反向
【发布时间】：2009-10-08 13:04:57
【问题描述】：

我很欣赏 TDD 并认为它不可或缺，但总是只在我编写源代码然后相应地重构之后才编写我的测试。我永远不能让自己先写测试然后源代码才能通过测试。所以我总是颠倒这个过程。这对我来说是一种不好的做法吗？像我这样倒过来有什么坏处？

【问题讨论】：

【解决方案1】：

如果您不先编写测试，那么它可能不是 TDD。使用 TDD，您通常会编写测试，观察它失败，然后实施以使其通过。

与您的工作流程相比的优势是：

您的测试可能会失败！创建一个不会失败的测试太容易了。正如 Eric 指出的那样，如果您不先编写测试，然后看着它失败，您怎么知道测试实际上是在测试您刚刚实现的功能？
您的代码绝对是可测试的。尽管我确信您遵循可测试技术，但测试优先开发可确保代码绝对是可测试的，否则您将不会编写代码:-)
“颠倒”解决方案。值得商榷的是，TDD 让您考虑“您需要什么”而不是“实施细节”。通过首先生成测试，您可以将测试中的一般架构/类结构拼凑起来，然后再了解实现细节。

您可以降低所有这些方面的风险，因此您是想继续保持原样还是先进行测试，这取决于您自己。

【讨论】：

【解决方案2】：

如果您在之后编写测试，它们真的会推动开发/设计吗？我不这么认为。

扩展 Steven Robbins 的回答：如果您的测试在通过之前没有失败，您怎么知道它正在测试正确的东西？

【讨论】：

【解决方案3】：

设计是由测试考虑驱动的吗？如果是这样，那么测试推动了开发。这是应该发生的事情。

首先编写测试绝对可以确保测试推动开发。而且它往往会限制重构。

如果您想先编写所有代码，然后进行重构，那么您就是在使用测试来推动开发（这很好）。但是，您可能会浪费时间先编写所有代码，然后再对其进行重构（这不太好）。使用 TDD 将有助于实现这一点；在代码之前编写测试还可以通过节省一些重构来减少开发时间。

【讨论】：

【解决方案4】：

相应地考虑您的软件设计和编码，然后添加测试以确保您没有忘记某些东西，这是我在书中继续进行的好方法。

您从软件设计和测试的角度来考虑您的代码。我倾向于并行开发代码和测试，从不遵循“先编写测试”范式，因为它往往会导致代码满足你的测试——而不是你的设计。

TDD 的风险在于忽略了设计阶段。如果您构建测试尝试以各种可能的方式破坏您的代码，那么修复您的测试带来的问题，您将获得稳定的代码。我不得不重构通过 TDD 编写的代码，充其量是原型质量，这不是提供好的代码的方法，而是你投入的精神努力。

【讨论】：

【解决方案5】：

自 2000 年以来，我一直在（正确地）进行 TDD。其他人提到了许多优点，但有一点非常很重要，并且在其他描述中缺失：

TDD 让你编写简单的代码！

当您进行 TDD 时，您先编写测试，然后编写绝对最简单的代码以通过测试。如果你反过来，那么你编写的代码通常比它需要的更复杂，并且会产生意想不到的副作用。

TDD 是一门非常困难的学科，但它很重要，因为它类似于外科医生在手术前对其器械进行消毒。如果您不进行消毒，您就有感染患者的风险。如果您不先编写测试，您的代码可能会因技术债务而感染。

【讨论】：