追求代码质量 - 通过测试分类实现矫捷构建[Java编程]

假如这样说不会（令您）很痛楚的话,请假想您是一名任职于一家 2002 年 早期成立的公司的开辟人员.在金钱的驱动下,您和您的团队接到了一项任务, 即便用最新且最强盛的 Java™ API 构建一个大型的数据驱动的 Web 利用 程序.您和公司管理层都刚强不疑地相信这就是终究将被称为矫捷历程 的东西 .从第一天起,您就用 JUnit 构建测试,且把它作为 Ant 构建历程的一部份尽 大概频繁地运行.还将设置一个按时任务在夜间运行构建.在接下来的某个时刻 ,有人会下载 CruiseControl,不断增长的测试套件会在每次签入时运行.

时至本日

经过过去几年的勤奋,您的公司已经开辟了一个宏大的 代码库和一个一样宏大的 JUnit 测试套件.一切都很正常,直到大约一年前, 测试套件包含了 2000 个测试,同时人们开始注意到运行构建历程用时超越三个 小时.在此之前的几个月,由于 CI 服务器资源慌张,您在代码签入时通过 Continuous Integration（CI）终止运行单元测试,并将测试切换到夜间运行, 这使得之后的早晨时间非常慌张,于是开辟人员勤奋去弄清楚是什么出错以及为 什么出错.

这些天,仿佛测试套件整晚极少超越一次运行,为什么会这样呢?因为它们 费时太多!没人会仅仅为了弄懂得系统能否运行杰出而几个小时守在那边.此外 ,整个测试套件都是在晚上运行,不是吗?

由于测试运行得太不频繁, 它们常常充满了错误.因而,您和您的团队开始质疑单元测试的代价:假如它们 对代码质量那么重要,那又为什么会让人这么头痛呢?你们的结论是:单元测试 有其重要的作用,但必必要能用一种更为矫捷的方法运行它们.

尝试测 试分类

您所需求的是一个将构建转换到一种更为矫捷状况的战略.您需求这样一种 办理筹划,使一天当中运行测试的次数超越一次,并使测试套件恢复到要用三个 小时才能完成构建之前的水平.

为完好地恢复整个测试套件,在试图提出一个战略之前,很有必要弄清楚通 用术语 “单元测试” 的含义.诸如 “我家有一个动物” 和 “我喜好车” 这 样的表述并不很具体,“我们编写单元测试” 也是一样.这年初,单元测试能 代表一切.

就拿之前有关动物和车的表述来说:它们招致了更多的疑问.比方,您家有 哪类动物?是一只猫、一条蜥蜴还是一头熊?“我家有一头熊” 和 “我家有一 只猫” 截然差别.一样,当和汽车贩卖员扳谈时,只说 “我喜好车” 没什么 用处.您喜好哪类车:赛车、卡车还是观光车?任何一个答案都能带来截然差别 的后果.

一样,关于开辟人员测试来说,按照范例 将测试分类也是很有效的.这样做 可以实现更为切确的语言,并且能使您的团队以差别的频率运行差别的测试范例 .为了避免运行全部 “单元测试” 所需的令人惊骇的三小时构建时间,分类是 关键.

三种范例

测试套件可以形象地分为三层,每一层代表一种差别的开辟人员测试范例, 该测试范例由其运行时间的长短决意.正如在图 1 中看到的那样,每一层都增 加了总的构建时间,要末增添了运行时间,要末终究增添了编写时间.

图 1.测试分类的三个层次

底层由运行时间最短的测试构成,可以想象的到,它们也最易于编写.这些 测试占用的代码量也是最少的.顶层由更高级别的测试构成,这些测试占用了应 用程序更大的部份.这些测试有一点难于编写,履行时间也要长得多.中间层是 处于这两个极度中间的测试范例.

三种范比方下所示:

单元测试

组件测试

系统测试

　　以上是“追求代码质量 - 通过测试分类实现矫捷构建[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：