测试驱动开发是一个骗局？

Question

请原谅我的标题有点挑衅。我会举个例子。假设您需要编写程序来构建汽车。这是一个测试程序：

public void testCarBuilder()
{
  expectedCar=someCar;
  actualCar=carFactory.build(bigWhell, yellowBodyCar);
  assertEqual(expectedCar, actualCar);
}

要知道要制造汽车，我们需要一个将车轮和carBody作为参数的功能，它至少应该对程序进行分析。这种分析可以用自然语言，UML甚至直接用编程语言编写！我们可以将这种分析写在一张纸上，将其留在我们的大脑中，或写入文件。 分析已经是一个程序的骨架！所以在测试之前总是至少有一个程序框架写入！ 假设开发任务从编写测试开始是sybyllin，总有一个第一个骨架程序（我们可以调用分析）来编写。除非有人告诉我如何可能相反。

Answer 1

有些人首先会写一个测试。
事实上，你刚刚在问题中写了一个测试。 您的测试可能会告诉您接下来需要编写的代码，但是您已经发现在之后在问题中编写了测试。

Answer 2

我将您的问题解释为您想知道在进行TDD时设计是如何出现的。

为了编写测试，您必须定义测试应该与之交互的边界/表面/外观。此设计活动是预先完成的。增长和变化的设计是在测试边界另一侧的设计。

在您的（平凡）示例中，测试帮助您发现的设计是carFactory内的设计。这不是很有用，所以我会说你的测试不是那么好。

TDD内有不同的学校。我实践的那个人提倡你从外部和外部进行测试。你选择一个尽可能接近系统边界的测试边界。例如，您让测试模拟用户界面中的按钮单击。执行此操作时，您可以在该按钮单击的另一侧自由更改整个系统的设计。

在您的示例中，您为什么要创建汽车？用户做了什么来触发此代码，以及用户如何告诉她想要完成的任何工作？这就是你在考试中应该拥有的。