在 TDD 中，当要测试的函数未定义时，您如何首先编写测试？

如果你什么都没有，你就不能写测试，因为没有什么可测试的。这对我来说似乎很明显，但 TDD 的支持者似乎从未解决过这个问题。

为了编写测试，您必须首先决定要测试的方法或函数是什么样的。您必须知道要传递给它的参数以及期望返回的参数。这才是最重要的，而不是测试。

测试永远不会排在第一位。首先是设计，它指定了将要存在哪些类和方法。

相反。

如果您编写的测试调用了一个不存在的函数，那么您的测试套件就会失败，并且您会收到一个错误，迫使您定义该函数，就像编写任何其他测试会迫使您编写实现一样。

您的测试不需要运行即可成为好的测试。但是这种测试并不意味着留在您的测试套件中。它们有时被称为“阶梯测试”：您需要编写它们才能开始，但它们只是工具性的。

通常情况是，一旦此测试通过，您就可以通过更具体的方式使其失败。从技术上讲，您最终得到的测试与事后编写的测试相同，并且不需要花费更多时间来编写它，但是在此过程中，您可以运行测试套件一次或多次，因此您可以这么说，花更少的时间处于无效状态。

我想补充一点，您的问题中没有任何不真实的地方，但您的结论不符合前提：确实首先是规范，但与在测试中形式化此规范并无不一致之处在写代码之前。规范和测试迫使您编写代码。 TDD 是规范规范的增量方式，可确保规范始终排在第一位。

要编写测试，您必须首先决定要测试的方法或函数是什么样的。您必须知道要传递给它的参数以及期望返回的参数。那是最先出现的，而不是测试。测试永远不会是第一位的。首先是设计，它指定了将要存在哪些类和方法。

不太正确（也不是完全错误 - 它很复杂[tm]）

如果您查看示例测试驱动开发中的第一个示例，您会发现 Beck 并没有从类和方法开始。他甚至没有从测试开始。

他创建的第一件事是“待办事项”列表，其中待办事项列表中的每个条目都代表一种行为（我的术语，不是他的术语）。所以我们看到像

这样的东西

$5 + 10 CHF = $10 if rate is 2:1

现在，您更有可能看到这个想法表达为 Hoare 三元组（Given/When/Then、Arrange/Act/Assert 等）。但是我们在这里提醒程序员，我们需要一个自动检查来衡量将两种不同货币相加的结果，并确认结果与某些规范相匹配。

在他的练习中，他的待办事项列表包括一个“更简单”的测试，这是他首先尝试的测试

$5 * 2 = $10

同样的待办事项列表还包括一些关于设计的其他问题，未以测试形式表达。此外，当他解决问题时，列表会增加。

从这个意义上说，测试绝对是第一位的。我们用人类可以使用的语言编写测试。稍后将测试翻译成机器理解的语言。

在我们向机器描述测试的第二步中，事情变得更加混乱。绝对是这样，在我们设计测试的同时，我们也在设计通信协议，允许测试测量生产代码的作用。因此，有一定数量的通信设计与“测试”设计同时进行。

但即使在这里，测试也没有指定所有将要存在的类，它只是指定执行测量所需的内容。我们描述了一个立面，但我们并没有具体说明立面之外是什么。

当我们设计更多系统时，可能会发生我们指定的外观仅供测试使用，作为与生产代码的不同底层设计进行通信的一种方式。

（注意：我在这里说类是为了与问题和早期文献保持一致，主要取自 Smalltalk 或 Java 中的示例。如果这让您更舒服，请随意用“函数”替换“类”。）>

现在，最常见的情况是门面是生产代码；我们通常不会在设计中添加元素，除非我们对它们有非推测性的动机。

“单元测试”给这些想法带来了一些压力 - 你怎么可能在不首先设计单元边界的情况下编写单元测试？

真正的答案是不幸的——Kent Beck 没有编写单元测试。他编写了“程序员测试”（这个术语后来被重新使用）并将它们称为单元测试。

使用 1990 年代的测试语言（所有这些混乱开始的时候），更合适的术语可能是“复合测试”。

你还有“伦敦学派”，它试图弄清楚如何 TDD 特定的设计风格；为该风格编写测试需要“预先”更复杂的测试外观（角色和接口以及稳定的替代实现等）。

记住设置也是值得的。

（免责声明：这不是我亲眼所见的 - 认为“基于真实故事”而不是“事实”）

TDD（及其在 XP 中的父思想“测试优先”编程）正在反对那种由您决定类层次结构和关系应该是什么并记录它们的“预先设计”，之前你实际上是坐下来写代码的。

核心论点是设计过程需要更短的反馈循环；直到我们获得大量证据表明它会正常工作，我们才会深入致力于特定的设计。

综上所述，是的，TDD 作为一种技术，在已经擅长软件设计的人手中效果更好。参见 Look,Ma,no hands! 时代的 Michael Feathers。

没有魔法。

确实，为了编写测试，测试编写者必须对测试代码如何与被测系统交互形成一些概念。从这个意义上说，概念设计“至上”。

然而，测试驱动开发 (TDD) 很有价值，因为它不是（仅）一种质量保证方法。这首先是一个快速反馈循环。

虽然您可能已经有了初始设计，但一旦开始编写测试，您可能会发现此设计不起作用（或使用起来很尴尬）。这种情况经常发生，应该会导致您立即调整路线。

red-green-refactor cycle 提出了一个考虑 TDD 的模型。每个这样的周期可能是一两分钟。

因此，您可以从最初的设计开始，然后每隔一分钟进行调整（或完全重新考虑）。

TDD 的支持者似乎从未解决过

我不同意。很多关于 TDD 的介绍都讨论了这一点。两本讨论这个（以及更多）的好书是 Kent Beck 的示例测试驱动开发和 Nat Pryce 和 Steve Freeman 的Growing Object-Oriented Coded by Tests。