2

在进行 TDD 时，我担心测试的“诚实”。TDD 是

  1. 写红色测试
  2. 编写足够的代码使其变绿
  3. 重构，让测试变绿

到现在为止还挺好。现在这里是一个应用上述原理的例子，这种例子在教程和现实生活中已经遇到过：

我想检查当前用户电子邮件是否显示在我的 web 应用程序的默认页面上。

  1. 编写一个红色测试：“example@user.com”显示在 default_page.html 中
  2. 编写足够的代码使其变为绿色：在 default_page.html 中硬编码“example@user.com”
  3. 通过实现 get_current_user()、其他一些层中的一些其他代码等进行重构，让测试变为绿色。

我对第 2 步感到“震惊”。这里出了点问题：即使没有任何实际工作，测试也是绿色的。这里有一种测试气味，这意味着也许在某些时候有人可以在不破坏测试套件的情况下破坏生产代码。

我在这里想念什么？

4

3 回答 3

7

您关于“没有任何工作”的断言是错误的。对于电子邮件地址为 example@user.com 的情况，该代码可以正常运行。而且您不需要最后的重构。您的下一个失败测试可能是在用户拥有不同电子邮件地址的情况下使其失败。

于 2014-10-20T08:23:10.567 回答
6

我会说你所拥有的只是部分完成。你说：

我想检查当前用户电子邮件是否显示在我的 web 应用程序的默认页面上。

该测试不会检查默认页面上的当前用户电子邮件地址，它会检查页面中是否存在固定的电子邮件地址“example@user.com”。

要解决这个问题，您要么需要提供更多示例（即有多个具有不同电子邮件地址的测试），要么需要在测试设置中随机生成电子邮件地址。

所以我会说你所拥有的是这样的伪代码：

Given current user has email address "example@user.com"
When they visit the default page
The page should contain the email address "example@user.com"

这是您可以在 TDD 中编写的第一个测试，您确实可以对其进行硬编码以避免实现不必要的东西。您现在可以添加另一个测试，这将迫使您实施正确的行为

Given current user has email address "example2@user.com"
When they visit the default page
The page should contain the email address "example2@user.com"

现在您必须删除硬编码，因为您无法使用硬编码解决方案同时满足这两个测试。因此，这将迫使您从当前用户那里获取实际的电子邮件地址并显示它。

通常在测试中以 3 个示例结束是有意义的。这些不需要是 3 个单独的测试，您可以使用数据驱动测试来重用具有不同值的相同测试方法。你没有说你用的是什么测试框架，所以我不能举一个具体的例子。

这种方法在 TDD 中很常见，称为 triangualtion。

于 2014-10-20T08:20:26.353 回答
0

你是对的

步骤 2. 这里有问题

但它不在TDD方法中。恕我直言，它在测试逻辑中。毕竟这（第 2 步）验证了测试工具是否正常工作。新测试不会在不需要任何新代码的情况下错误地通过，并且所需的功能尚不存在。

我在这里想念什么？

这一步也应该测试测试本身，是否定的：它排除了新测试总是通过的可能性，因此毫无价值。由于预期的原因，新测试也应该失败。至关重要的是，此步骤增加了开发人员对其正在测试正确事物的信心，并且仅在预期的情况下通过。

于 2014-10-20T07:55:03.863 回答