关于测试深度的介绍(DOT)
在过去的几年中我对于参与关于尽可能贴近代码本身来编写测试的团体以及将其应用于我的测试项目特别有热情。因此我能够实现更简单，更低成本的测试金字塔，而不是高成本而且脆弱的雪糕筒模型。我的激情源于一切我见到的，我自己写的测试套件，并试图通过用户界面来实现高场景覆盖率。我是在旨在收集新思想的ThoughtWorksTechnology Radar会议中关于这一技术的热烈拥护者之一。现在我很满意地看到，这项技术近被添加到新一期radar的已采用一节。
适当层次的测试 “BDD的出现，使得类似Cucumber的测试框架，加上类似Selenium的浏览器自动化工具，大幅促进了在浏览器级别使用验收测试。不幸的是这鼓励了将测试的大部分在运行成本是大的情况下进行。相反，我们应该在适当层次进行测试，例如尽可能贴近代码，以便测试能够以高效运行。浏览器级别的测试应该是锦上添花的部分，是由适当层次执行的验收测试和单元测试来支持” ——thoughtworks.com/radar 浅层测试 我相信一个新定义的隐喻，沃德·坎宁安所说的技术债务，对于解释这个内容来说非常有效。我将解释一个现实世界的例子，终我会得到我新定义的词：浅层测试。 比方说，假设我从来没有尝试过其中的一个，我们需要实现一个报价的web应用程序，它有几个业务规则验证，如果提供的细节是有效的，它会为用户提供报价。从用户的角度来看，应用程序是这样的:
让我们记住，我们要避免对这个系统进行一个黑盒测试，所以让我们把它分解开来并理解里面都有哪些部分。该系统的架构在下面的图片中进行了更为详细的解释： Javascript层，使用JSON服务与服务器端进行通讯 控制器和强制验证 领域模型，业务规则和定价计算器 数据存储
定价计算器是该系统的重要组成部分。它必须经过严格的测试以确保它在不同的情况下都能提供正确的价格.如果我们通过用户界面来测试定价系统，使用类似webdriver/Selenium的工具，或者任何其他根据下图所示流程驱动浏览器逐个访问内容的工具，我称呼这些模块为焦点区域。 在定价方面，会有好几个场景，也许几十个，有时甚至几百个不同因素的组合，可能会影响支付金额。这意味着在我们对价格计算器进行测试时，我们将要多次访问这些模块。换句话说，当我们测试定价计算器模块时，所有的都是焦点区域。
下面是我是如何想到提出这个比喻的…在光学上，特别是在电影和摄影，有个叫景深的概念： “景深（DOF）是在一个场景中可取得清晰图像的近和远的物体之间的距离。”
因此，将其引申到软件测试中： “测试深度（DOT）是一个测试的执行过程中需要访问的近和远的软件模块之间的距离”。 在这里有必要指出定义中提到了“软件模块”，这不一定指的是一个“类”（OOP），或者一个“功能”（FP）。模块是执行系统中的一个小功能的逻辑实体。它可以是一个完整的定价计算器，业务规则验证或简单的字符串连接功能。每个系统将其尺寸不一的模块。 确定了上述定义后，如果我们想测试上面提到的定价计算器，我们应该保持焦点，并在不同层次对其进行测试，而不是通过用户接口，在这种情况下也是浏览器。如果我们这样做的话，我们能做到浅层测试。
我所学到的和观察到的是，越是浅层的测试，维护越是便宜，执行也越快。
