如果您一无所有，则无法编写测试，因为没有要测试的东西。这对我来说似乎很明显，但似乎从未被 TDD 的支持者解决。
为了编写测试，您必须首先确定要测试的方法或函数是什么样的。您必须知道要传递给它的参数以及期望返回的参数。那是第一位的，而不是测试。
测试永远不会是第一位的。首先是设计，它指定了哪些类和方法将存在。
问问题
191 次
3 回答
2
反之亦然。
如果您编写的测试调用了一个不存在的函数，那么您的测试套件将失败，并且您会收到一个错误，迫使您定义该函数，就像编写任何其他测试会迫使您编写实现一样。
您的测试不需要运行即可成为好的测试。但是这种测试并不意味着留在你的测试套件中。它们有时被称为“阶梯测试”：您需要编写它们才能开始，但它们只是工具性的。
通常发生的情况是，一旦此测试通过，您就会通过更具体的方式使其失败。从技术上讲，您最终得到的测试与事后编写的测试相同，并且不需要花费更多时间来编写它，但是在此过程中您可以运行测试套件一次或多次，因此您可以这么说，在无效状态下花费的时间更少。
我想补充一点，你的问题没有什么不真实的，但你的结论并不遵循前提：首先是规范是正确的，但是在代码之前的测试中形式化这个规范没有什么不一致的是写的。规范和测试迫使您编写代码。TDD 是一种形式化规范的增量方式，可确保规范始终位于首位。
于 2021-03-18T10:19:52.390 回答
2
要编写测试，您必须首先确定要测试的方法或函数是什么样的。您必须知道要传递给它的参数以及期望返回的参数。这是第一，而不是测试。测试永远不会是第一位的。首先是设计，它指定了哪些类和方法将存在。
不太正确（也不是完全错误 - 它很复杂[tm]）
如果您看一下 Test Driven Development by Example 中的第一个示例，您会发现 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 作为一种技术，在已经擅长软件设计的人手中工作得更好。看看迈克尔羽毛的外观，妈，没有手！时代。
没有魔法。
于 2021-03-18T14:09:07.833 回答
1
确实，为了编写测试，测试编写者必须对测试代码如何与被测系统交互形成一些概念。从这个意义上说，概念设计“是第一位的”。
然而，测试驱动开发 (TDD) 很有价值，因为它不是（仅）一种质量保证方法。它首先是一个快速反馈循环。
虽然您可能有一个初始设计，但一旦您开始编写测试，您可能会发现此设计不起作用（或使用起来很尴尬）。这种情况经常发生，应该会导致您立即调整路线。
红-绿-重构周期建议了一个考虑 TDD 的模型。每个这样的循环可能是一两分钟。
因此，您可能会从最初的设计开始，然后每隔一分钟对其进行调整（或完全重新考虑）。
TDD 的支持者似乎从来没有提到过
我不同意。对 TDD 的大量介绍讨论了这一点。讨论这个（以及更多）的两本好书是 Kent Beck 的Test-Driven Development by Example和 Nat Pryce 和 Steve Freeman 的成长型面向对象的代码，由测试指导。
于 2021-03-19T07:01:39.357 回答