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写道：
虽然集成测试少得可怜，但所有事情都被独立测试过了——每一个组成部分都很干净、独立、被良好测试并且可以信任其正确性，(这也是单元测试的极限了)。但是如何保证所有组件都能协同工作呢?这是一个灰色(甚至黑色)区域，除非能充分地结合单元测试和集成测试。
文章来源于领测软件测试网 https://www.ltesting.net/
