关于测试驱动开发,但反过来

如果您不先编写测试,那么可以说它不是TDD。使用TDD,您通常会编写测试,观察它是否失败,然后执行以使其通过。

与您的工作流程相比,其优势在于:

• 你的测试可能会失败!创建一个不能失败的测试太容易了。正如Eric指出的那样,如果你不先编写测试,然后看着它失败,你怎么知道测试实际上是在测试你刚刚实现的功能呢?
• 您的代码是可测试的。尽管我确信您遵循可测试的技术,但是测试优先开发确保代码是可测试的,否则您就不会编写代码了:—)
• 把你的解决方案颠倒过来。有争议的一点是,但TDD让您思考“您需要什么”,而不是“实现细节”。通过首先生成测试,您可以将一般的体系结构/类结构组合到测试中,然后了解实现细节。

你可以降低所有这些点的风险,所以你是想继续按你的方式前进,还是先切换到测试。

如果您随后编写测试,它们真的驱动开发/设计吗?我不这么认为。

扩大史蒂文·罗宾斯的回答:如果你的考试在通过之前没有失败, 你怎么知道它在测试正确的东西? ?

思考一下你的软件设计和相应的编码,然后加上测试以确保你没有忘记一些东西,这是在我的书中继续进行的一个好方法。

从软件设计和测试的角度考虑代码。我倾向于在Parralell中开发代码和测试,永远不要遵循“先编写测试”范式,因为它往往会导致代码满足您的测试,而不是您的设计。

TDD的风险在于设计阶段被忽略了。如果您构建的测试试图以各种可能的方式破坏代码,那么请修复测试带来的问题,从而获得稳定的代码。我不得不重构通过TDD编写的代码,这些代码最好是具有原型质量的,它不是交付好代码的方法,而是您在其中投入的精神努力。

设计是否由测试因素驱动?如果是这样,那么测试驱动了开发。这就是应该发生的事情。

首先编写测试绝对可以确保测试驱动开发。而且它也限制了重构。

如果您想先编写所有代码,然后重构,那么您将使用测试来驱动开发(这很好)。但是,您可能会浪费时间先编写所有代码,然后再重构所有代码(这不太好)。使用TDD将有助于实现这一点;在代码之前编写测试还将节省一些重构,从而缩短开发时间。

我从2000年就开始做TDD了。其他人提到了很多优点,但有一点是 非常 重要,其他描述中缺少:

TDD让您编写简单的代码!

当您执行TDD时,您编写测试,然后编写绝对最简单的代码来通过测试。如果您颠倒了这一点,那么通常您编写的代码比需要的要复杂,并且会产生意想不到的副作用。

TDD是一门非常困难的学科,但它很重要,因为它可以与外科医生在手术前对器械进行消毒相媲美。如果你不消毒,你就有感染病人的风险。如果您不首先编写测试,那么您可能会因为技术债务而感染代码。