TDD和"诚实"的考验

Question

在做TDD时我对测试的"诚实"感到担忧.TDD是

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

到现在为止还挺好.现在这里是一个应用上述原则的例子,在教程和现实生活中已经满足了这样的例子:

我想检查当前用户电子邮件是否显示在我的webapp的默认页面上.

1. 写一个红色测试:"example@user.com"显示在default_page.html中
2. 编写足够的代码使其变为绿色:在default_page.html中硬编码"example@user.com"
3. 通过实现get_current_user(),其他一些层中的其他代码等来重构,让测试变为绿色.

我对第2步感到"震惊".这里有一些问题:即使没有任何实际工作,测试也是绿色的.这里有一种测试气味,这意味着可能在某些时候有人可能会破坏生产代码而不会破坏测试套件.

我在这里缺少什么？

Answer 1

你的断言"没有任何工作"是错误的.对于电子邮件地址为example@user.com的情况,代码正常运行.而且你不需要最后的重构.您的下一次失败测试可能是因为用户具有不同的电子邮件地址而导致失败.

Answer 2

我会说你所拥有的只是部分完成.你说:

我想检查当前用户电子邮件是否显示在我的webapp的默认页面上.

测试不会检查默认页面上的当前用户电子邮件地址,它会检查固定电子邮件地址"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中很常见,称为三角形.