在过去的几年中我对于参与关于尽可能贴近代码本身来编写测试的团体以及将其应用于我的测试项目特别有热情。因此我能够实现更简单，更低成本的测试金字塔，而不是高成本而且脆弱的雪糕筒模型。我的激情源于一切我见到的，我自己写的测试套件，并试图通过用户界面来实现高场景覆盖率。我是在旨在收集新思想的ThoughtWorksTechnology Radar会议中关于这一技术的热烈拥护者之一。现在我很满意地看到，这项技术最近被添加到最新一期radar的已采用一节。
适当层次的测试
“BDD的出现，使得类似Cucumber的测试框架，加上类似Selenium的浏览器自动化工具，大幅促进了在浏览器级别使用验收测试。不幸的是这鼓励了将测试的大部分在运行成本是最大的情况下进行。相反，我们应该在适当层次进行测试，例如尽可能贴近代码，以便测试能够以最高效运行。浏览器级别的测试应该是锦上添花的部分，是由适当层次执行的验收测试和单元测试来支持”
——thoughtworks.com/radar
浅层测试
我相信一个新定义的隐喻，沃德·坎宁安所说的技术债务，对于解释这个内容来说非常有效。我将解释一个现实世界的例子，最终我会得到我新定义的词：浅层测试。
比方说，假设我从来没有尝试过其中的一个，我们需要实现一个报价的web应用程序,它有几个业务规则验证,如果提供的细节是有效的,它就会为用户提供报价。从用户的角度来看,应用程序是这样的:
让我们记住，我们要避免对这个系统进行一个黑盒测试，所以让我们把它分解开来并理解里面都有哪些部分。该系统的架构在下面的图片中进行了更为详细的解释：
Javascript层，使用JSON服务与服务器端进行通讯
控制器和强制验证
领域模型，业务规则和定价计算器
数据存储
