Question

也许有人可以帮助我理解＆＃34;测试驱动开发＆＃34;方法。我自己尝试了以下示例，我不知道我的理解问题在哪里。

假设我们需要一个函数来回馈两个数字a和b的总和

为了确保该功能正常，我写了几个测试。就像创建sum-object一样，检查a和b是否是数字等等。但是第一个＆＃34;真正的测试＆＃34;正确计算的是以下

a=3
b=3
expected value: 6

TDD方法只允许我们执行许多步骤让测试通过。所以函数看起来像

sum(a, b){
 return 6
}

测试＆＃34; 3 + 3＆＃34;将通过。

接下来的测试是＆＃34; 4 + 10＆＃34;也许

我将运行测试，最后一次测试将失败。多么令人惊讶......

我将我的功能改为

sum(a, b){
 if(a=3 and b=3)
  return 6
 else
  return 14
}

测试将通过！

这种情况一直持续......我只会为每次测试添加另一个案例。该函数将通过每个测试，但对于其他未列出的情况，它不会，结果是一个无效且愚蠢的书面函数。

所以有一个万无一失的＆＃34;技巧＆＃34;不要陷入这种思维方式？我认为，测试驱动的开发是非常直接和愚蠢的证据。＆＃34;收支平衡＆＃34;当时间说，这种做测试的方式不再可行并切换到正确的解决方案

return a+b;

???

这是一个非常简单的例子，但我可以想象，有更复杂的功能显然不像这个那么容易纠正。

由于

Answer 1

TDD工作流程有3个部分循环（＆＃34;红色，绿色，重构＆＃34;），重要的是不要跳过第三部分。例如，在您的第二个版本之后：

sum(a, b){
 if(a=3 and b=3)
  return 6
 else
  return 14
}

你应该看看这个并问：有没有更简单的方法来写这个？嗯，是的，有：

sum(a, b){
 return a+b
}

当然，这是一个不切实际的简单例子，但在现实编码中，第三步将指导您将代码细化为编写良好，经过测试的最终版本。

Answer 2

编写测试的基本思想是知道您的系统是否按预期运行。在测试中，我们做出了期望，假设。基本上，我们做了以下

我们设定了对特定条件的期望，并根据实际输出进行测试。作为开发人员，产品所有者，我们总是知道系统应该如何处理任何给定的条件，我们会相应地编写测试。

例如，对于下面给出的伪代码：

int sum(int a, int b) {
    return a + b;
}

这里方法sum应该返回参数a和b的总和。我们知道，

所以，我们确切地知道什么时候会失败，我们应该编写测试来覆盖至少70％的案例。

我是一个PHP人，所以我的例子是PHP。关于，提供参数a，b的方法。我们有一个叫数据提供者的东西我在这里给PHP作为参考，在PhpUnit中，传递不同参数的首选方法是将其传递给Dataprovider。访问dataprovider示例，您将看到添加的示例。

这种情况一直持续......我只会为每次测试添加另一个案例。该函数将通过每个测试，但对于其他未列出的情况，它不会，结果是一个无效且愚蠢的书面函数。

是的，我们尽量覆盖尽可能多的案例。覆盖的测试越多，我们对代码的信心就越大。假设我们已经编写了一个方法，该方法返回数组的子集，每个子集中包含4个唯一元素。现在，您如何为它编写测试用例？其中一个解决方案是计算排列并检查不应超过数组最大计数的数组长度（每个唯一元素）。

当它的时间说，这种做测试的方式不再可行并切换到正确的解决方案时，“收支平衡点”在哪里

我们在测试案例中没有收支平衡。但我们在不同类型的测试用例中做出选择，即（单元测试，功能测试，行为测试）。开发人员应该执行哪种类型的测试，具体取决于测试的类型。

最好的方法是在项目中实施TDD。直到我们在实际项目中这样做，才会产生混淆。我自己很难理解模拟和期望。这不是可以在一夜之间学到的东西，所以如果你不理解某些东西，这是正常的。自己尝试一下，给自己一些时间，做实验问朋友，不要筋疲力尽。总是很好奇。

如果您仍然对此感到困惑，请告诉我们。