unit-testing - TDD和测试的 "honesty"

标签 unit-testing testing tdd atdd

在进行 TDD 时,我担心测试的“诚实”。测试驱动开发是

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

到目前为止一切顺利。下面是一个应用上述原则的例子,这种例子在教程和现实生活中已经遇到过:

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

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

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

我在这里缺少什么?

最佳答案

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

关于unit-testing - TDD和测试的 "honesty",我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26460379/

相关文章:

c++ - 存储测试数据

c# - 最小起订量和 "as"关键字

scala - 在 scala 中模拟会生成 java.lang.NoSuchMethodException

python - 检查模板失败,因为 "No templates used to render the response"

tdd - 以敏捷方式实现用户故事

javascript - Jasmine,测试 Javascript 对象是否包含另一个 Javascript 对象

wpf - 单元测试 WPF 绑定(bind)

performance - 如何参数化json文件中的值 - loadrunner

javascript - Sinon spy.called 没有工作

testing - 测试驱动开发书籍