TDD/BDD 会导致不完整的单元测试吗?

  • Mike Bria
  • 韩锴

2008 年 2 月 24 日

话题:敏捷方法论测试架构文化 & 方法

Peter Ritchie 最近开始担心他认为很不妙的趋势,即开发者为了坚持TDDBDD 而无法写好单元测试。特别地,他认为对“交互测试”的顶礼膜拜,最终带来的后果是不完整的单元测试;测试无法证明某个单元(对象)能在它有可能工作的任何环境下正常工作。首先,Peter 的想法中,最有趣的部分可能就是 TDD 与 BDD 之间不同核心目的的冲突。

Peter 利用“类是真实世界概念的自然抽象”这一理念作为自己观点的基础。他认为良好的单元测试 应该能够验证这些自然抽象出来的类,但可能在未来的某个时刻开始,TDD 和 BDD 将导致人们不去遵守这一原则:

我发现测试驱动开发(TDD)和行为驱动开发(BDD)这两种方法结合在一起后存在一个问题,那就是实践者只把系统各部分间的交互放在了最核心的位置,其实并没有做任何“单元测试”。他们只为了追随 TDD 和 BDD 的魔咒,最后却只见树木、不见森林,而成为盲目测试。单元测试的目标是独立的单元、应用程序中最小的可测试的部分。

Peter 引用了Wikipedia's BDD entry中的一个例子来证明他的观点:

详细的测试仅测了 4,294,967,296 种可能性中的 13 种。这些测试可能很好地测试了一个系统预期的行为,但是并没有真正把 EratosthenesPrimesCalculator 当作一个单元来测试。如果系统只允许这样的行为,那么这些测试可以证明系统是正常的。但是,如果 EratosthenesPrimesCalculator 超出了这 13 种行为而被使用的话(这也正是将代码封装成类的目的:重用),那么它就算不是上已测试好的啦。

这个例子在很大程度上依赖于这样一个观点——一个单元的有效性 / 正确性完全是基于其名字所暗示的在现实世界中它所固有的特性。很多 TDD 的实践者会向这一点发起挑战,他们认为:一个单元的有效性只能在使用它的环境(系统)上下文中才能定义。JMock 的作者之一Steve Freeman说道:

测试先行的交互测试的思想是理清一个对象与它的环境之间的关系。例如,你正在模拟一个 DAO,但是 DAO 不是应用领域中一部分,它是实现领域的一部分。

而另一方面,很多做 TDD 培训的人会不认同这一点,他们认为:先行编写单元测试的主要作用在于它是一个单元模块该做什么、不该做什么的显式规约。下面文字源自于 Mario Gleichmann 的“TDD 与按契约设计的对比”:

单元测试作为测试驱动开发(TDD)的一个重要组成部分,其作用并不在于能在多大程度上验证实现的正确性,而是有助于澄清单元模块行为的规约。事实上,驱动开发的东西应该是规约,而不是验证。你可以在行为驱动开发(BDD)的崛起中看到这种思想的回归。BDD 其实就是要寻找一个充分的词汇表并用一种很自然的方式编写规约(当然,这也是可以被自动化测试的),以便将注意力重新放到“组件在特定条件下应具有哪种行为”这个问题上来。

从“单元模块是由其上下文定义的”这种观点中引申出来的一个推论经常被引用,这个推论就是:按照单元测试的定义,它并不能反映出整体系统的质量和有效性,相反,要想做到这一点,就要在开发阶段中增加各种级别的验收测试JS Greenwood写道:

虽然集成测试少得可怜,但所有事情都被独立测试过了——每一个组成部分都很干净、独立、被良好测试并且可以信任其正确性,(这也是单元测试的极限了)。但是如何保证所有组件都能协同工作呢?这是一个灰色(甚至黑色)区域,除非能充分地结合单元测试和集成测试。
查看英文原文TDD/BDD Leading To Incomplete Unit Tests?
敏捷方法论测试架构文化 & 方法