测试驱动开发理解问题答案

【问题标题】：Test Driven Development Understanding Problems测试驱动开发理解问题
【发布时间】：2016-09-08 14:38:12
【问题描述】：

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

假设我们需要一个函数来返回两个数字 a 和 b 之和

为了确保该功能正常工作，我编写了几个测试。就像创建 sum-object，检查 a 和 b 是否是数字等等.. 但是正确计算的第一个“真正测试”如下

a=3
b=3
expected value: 6

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

sum(a, b){
 return 6
}

“3+3”测试将通过。

下一个测试可能是“4+10”。

我将运行测试，最后一个测试将失败。真是惊喜……

我将我的功能更改为

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

测试将通过！

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

那么有没有万无一失的“诀窍”不陷入这种思维方式？我认为，测试驱动开发非常简单明了。 “收支平衡”点在哪里，是时候说这种测试方式不再可行并切换到正确的解决方案

return a+b;

???

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

谢谢

【问题讨论】：

【解决方案1】：

TDD 工作流程有一个由三部分组成的循环（“红色、绿色、重构”），重要的是不要跳过第三部分。例如，在您的第二个版本之后：

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

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

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

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

【讨论】：

【解决方案2】：

编写测试的基本思想是了解您的系统何时表现如预期。在测试中，我们做出期望、假设。基本上，我们做以下

我们针对给定条件设定预期，并根据实际输出对其进行测试。作为开发人员、产品负责人，我们始终知道系统在任何给定条件下的行为方式，并据此编写测试。

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

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

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

所以，我们确切地知道它什么时候会失败，我们应该编写测试来覆盖至少 70% 的这些情况。

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

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

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

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

我们在测试用例中没有收支平衡。但是我们在不同类型的测试用例中做出选择，即（单元测试、最佳功能测试、行为测试）。应该实施哪种类型的测试取决于开发人员，并且取决于测试的类型，它可能会有所不同。

最好的方法是在项目中实施 TDD。直到我们在实际项目中做到这一点，混乱才会继续存在。我自己很难理解模拟和期望。这不是一夜之间就能学会的东西，所以如果你不明白一些东西是正常的。自己尝试一下，给自己一些时间，与朋友一起做实验，不要感到筋疲力尽。永远保持好奇。

如果您对此仍有疑问，请告诉我们。

【讨论】：