1.摘要

最近一段时间打仗到了spock这个可以用于java和groovy项目标单位测试框架，写了一段时间单测之后认为这个框架不错，值得写一篇文章推广一下。

2.关于单位测试

许多人一谈到单位测试就会想到xUnit框架。对付一些java新人来说，会用jUnit就是会写单位测试，高级点的会捣鼓一下testng，然后就认为本身把握了单位测试。

而实际上，许多人不怎么会写单位测试，甚至不知道单位测试毕竟是干什么的。写单位测试要比写代码要难上很多，而这里说的难度跟框架没什么干系。

所以，在开始先容spock之前，需要先抛开框架，谈谈单位测试自己的工作。在领略了单位测试之后才气更清楚spock框架是什么，以及它否可以或许更优雅的办理你的问题。

2.1.1.单位测试是什么

写代码免不了要做测试，测试有许多种，对付java来说，最低级的就是写个main函数运行一下看当作果，高级的可以用各类高峻上的巨大的测试系统。每种测试都有它的存眷点，好比测试成果是不是正确，可能运行状态稳不不变，可能能遭受几多负载压力，等等。

那么所谓的单位测试是什么？这里直接引用维基百科上的词条说明：

单位测试（又称为模块测试, Unit Testing）是针对措施模块（软件设计的最小单元）来举办正确性检讨的测试事情。措施单位是应用的最小可测试部件。在进程化编程中，一个单位就是单个措施、函数、进程等；对付面向工具编程，最小单位就是要领，包罗基类（超类）、抽象类、可能派生类（子类）中的要领。

所以，我眼中的“及格的”单位测试需要满意几个条件：

1. 测试的是一个代码单位内部的逻辑，而不是各模块之间的交互。
2. 无依赖，不需要实际运行情况就可以测试代码。
3. 运行效率高，可以随时执行。

2.1.2.单位测试的定位

相识了单位测试是什么之后，第二个问题就是：单位测试是用来做什么的？

许多人第一回响是“看看措施有没有问题”，可能“确保没有bug”。单位测试确实可以测试措施有没有问题，可是，从我小我私家编程的履向来看，大部门环境下只是利用单位测试来“看看措施有没有问题”的话，效率反而不如把措施运行起来直接查察功效。原因有两个：

1. 单位测试要写特另外代码，而不写单位测试，直接运行措施也可以测试措施有没有问题。
2. 纵然通过了单位测试，措施在实际运行的时候仍然有大概出问题。

可是，许多时候直接启动措施测试会较量慢，所以一些同学为了办理这个问题，回收了一个折中的步伐：只加载要测试的模块和它所有的依赖模块，好比在测试时只加载这个模块相关的spring的设置文件。这时所谓的单位测试实际上是用xUnit框架运行的集成测试，并没有浮现“单位”的观念。

而关于“纯粹的单位测试”在先容语言可能框架的书里很少被提起，反而是先容重构可能火速开拓的书里常常会看到各类百般的关于单位测试的先容。

在这里我总结了一下几个较量常见的单位测试的几个典范场景：

1. 开拓前写单位测试，通过测试描写需求，由测试驱动开拓。
2. 在开拓进程中实时获得反馈，提前发明问题。
3. 应用于自动化构建或一连集成流程，对每次代码修改做回归测试。
4. 作为重构的基本，验证重构是否靠得住。

尚有最重要的一点：编写单位测试的难易水平可以或许直接回响出代码的设计程度，能写出单位测试和写不出单位测试之间浮现了编程本领上的庞大的鸿沟。无论是什么样的措施员，僵持编写一段时间的单位测试之后，城市明明感觉到代码设计本领的庞大晋升。

2.2.单位测试的痛点

对付新人来说，很容易在编写单位测试的时候碰着这几类问题：

2.2.1.单位测试的资料不足全

这里不足全是相对付“编码”来说的。先容如何编码、如何利用某个框架的书茫茫多，可是与编码同样重要的先容单位测试的书却不多，翻来覆去好的也不多，而且都有必然年初了。（假如有这方面的好的资料，请推荐给我，多谢）

许多关于编程的书籍中并没有深入先容如何举办单位测试，可能仅仅先容了最基本的assert、jUnit里怎么界说一个测试函数之类，就没有然后了，给人的感受是这样：

2.2.2.单位测试难以领略和维护