试着对TDD的好处有信心

The Art of Unit Testing 来自亚马逊。我对理解TDD非常认真,所以请放心,这是一个真正的问题。

但我觉得我一直在寻找理由放弃它的边缘。

我将在这里扮演魔鬼代言人的角色,并试图击落所谓的TDD的好处,希望有人能证明我错了,并帮助我对它的优点更有信心。我想我遗漏了什么,但我不知道是什么。

1.TDD减少错误

这个 often-cited blog post 说单元测试是设计工具,不是用来捕捉bug的:

以我的经验,单元测试不是 找到错误或检测回归的有效方法。

TDD是一种健壮的设计方法 软件组件(单元) 是通过单元测试指定的。 就这些!

有道理。边缘案例仍然会一直存在,你只会发现表面的bug——不管怎样,只要你运行你的应用程序,你就会发现这些bug。在构建好软件之后,仍然需要进行适当的集成测试。

公平地说,减少bug并不是TDD应该帮助的唯一事情。

这可能是最大的。TDD是一种设计范例,它可以帮助您(或迫使您)使您的代码更加复杂 composable

例如,为了在数据库上执行业务逻辑,可以在一个函数中隔离IO代码,该函数执行访问数据库并将其作为参数传递给负责业务逻辑的函数的“一元”任务。这将是一种实用的方法。

当然,这有点笨拙,因此我们可以将数据库IO代码的一个子集扔到类中,并将其交给包含相关业务逻辑的对象。它是完全相同的东西,是对功能性做事方式的一种调整,它被称为存储库模式。

3.TDD作为文件

当然,TDD方法可以作为示例代码的基础,但是测试通常包含一些不应该出现在示例代码中的模拟,并且通常都是精心设计的,因此可以根据预期结果对它们进行相等的评估。

一个好的单元测试将在它的方法签名中描述被验证的确切行为,并且测试将验证不多于也不少于该行为。

所以,我想说,你最好把时间花在完善你的文档上。见鬼,为什么不先彻底完成文档,并称之为文档驱动设计?

上面那篇文章提到TDD对于检测回归不太有用。当然,这是因为当您更改一些代码时,不明显的边缘情况总是会出错。

在这个话题上,值得注意的是 你的代码在很长一段时间内都会保持不变。所以,在需要的基础上编写单元测试是不是更有意义,只要代码被更改,就保留旧代码并将其结果与新函数的结果进行比较?