-5

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

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

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

4

2 回答 2

1

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

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

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

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

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

于 2013-08-01T06:24:37.263 回答
1

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

于 2013-07-31T08:47:24.690 回答