Peter Ritchie 最近开始担心他认为很不妙的趋势，即开发者为了坚持 TDD 与 BDD 而无法写好单元测试。特别地，他认为对“交互测试”的顶礼膜拜，最终带来的后果是不完整的单元测试；测试无法证明某个单元（对象）能在它有可能工作的任何环境下正常工作。首先，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 写道：
虽然集成测试少得可怜，但所有事情都被独立测试过了——每一个组成部分都很干净、独立、被良好测试并且可以信任其正确性，（这也是单元测试的极限了）。但是如何保证所有组件都能协同工作呢？这是一个灰色（甚至黑色）区域，除非能充分地结合单元测试和集成测试。
评论