你还在痛苦做单元测试吗？Spock in Java 让你变得轻松！

lsekfe

前言
　　最近小组里面引进了Spock这个测试框架，本人在实际使用了之后，体验非常不错，本篇文章一是为了巩固输入的知识，二是为了向大家推广一下。
　　在了解学习Spock测试框架之前，我们应该先关注单元测试本身，了解我们常见的单测痛点，这样才能更好地去了解Spock这个测试框架是什么，我们为什么要使用它，能解决我们什么痛点。
　　现在让我们开始吧。
　　关于单元测试
　　我们写代码免不了要测试，测试有很多种，对于Javaer们来说，最初级的测试是写个main函数运行一个函数结果，或者说把系统启起来自己模拟一下请求，看输入输出是否符合预期，更高级地，会用各种测试套件，测试系统。每个测试都有它的关注点，比如测试功能是否正确，系统性能瓶颈等等。
　　那我们常说的单元测试呢？
单元测试（英语：Unit Testing）又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
　　-- 摘自维基百科

以上是维基百科的说明。
　　单元测试当然不是必须之物，没了单测你的程序经过QA团队的端到端测试和集成测试之后，也能保证正确性。但是从另外的角度来看，单元测试也是必须之物。比如持续部署的前提之一就是有单元测试的保障，还有在重构代码的时候，没有单元测试你会寸步难行。
　　1.1 单元测试的好处
　　单元测试的好处包括但不限于：
　　·提升软件质量
　　优质的单元测试可以保障开发质量和程序的鲁棒性。越早发现的缺陷，其修复的成本越低。
　　· 促进代码优化
　　单元测试的编写者和维护者都是开发工程师，在这个过程当中开发人员会不断去审视自己的代码，从而（潜意识）去优化自己的代码。
　　· 提升研发效率
　　编写单元测试，表面上是占用了项目研发时间，但是在后续的联调、集成、回归测试阶段，单测覆盖率高的代码缺陷少、问题已修复，有助于提升整体的研发效率。
　　· 增加重构自信
　　代码的重构一般会涉及较为底层的改动，比如修改底层的数据结构等，上层服务经常会受到影响；在有单元测试的保障下，我们对重构出来的代码会多一份底气。
　　1.2 单元测试的基本原则
　　宏观上，单元测试要符合 AIR 原则：
　　A: Automatic（自动化）
　　I: Independent（独立性）
　　R: Repeatable（可重复）
　　微观上，单元测试代码层面要符合 BCDE 原则：
　　B: Border，边界性测试，包括循环边界、特殊取值、特殊时间点、数据顺序等
　　C: Correct，正确的输入，并且得到预期的结果**
　　D: Design，与设计文档相符合，来编写单元测试
　　E: Error，单元测试的目的是为了证明程序有错，而不是证明程序无错。为了发现代码中潜藏的错误，我们需要在编写测试用例时有一些强制的错误输入（如非法数据、异常流程、非业务允许输入等）来得到预期的错误结果。
　　1.3 单元测试的常见场景
　　开发前写单元测试，通过测试描述需求，由测试驱动开发。（如果不熟悉TDD的同学可以去google一下）
　　在开发过程中及时得到反馈，提前发现问题。
　　应用于自动化构建或持续集成流程，对每次代码修改做回归测试。（CI/CD 质量保障）
　　作为重构的基础，验证重构是否可靠。
　　1.4 单元测试的常见痛点
　　下列痛点是日常开发中可能会遇到的，
　　测试上下文依赖外部服务（如数据库服务）
　　测试上下文存在代码依赖（如框架等）
　　单元测试难以维护和理解（语义不清）
　　对于多场景不同输入输出的函数，单元测试代码量会很多
　　...
　　对上面几点稍微做下解释。
　　首先，测试代码的代码量绝对不会比业务代码少（假设有覆盖率指标，且不作弊），有时候一个函数，输入和输出会有多种情况，想要完全覆盖，代码量只会更多。较多的代码量，加上单测代码并不想业务代码那样直观（靠写注释的方式，看的乱，写的累），还有一部分编码人员对代码可读性不重视，最终就会导致单元测试的代码难以阅读，更难以维护。同时，大部分单元测试的框架都对代码有很强的侵入性，要想理解单元测试，首先得学习一下那个单元测试框架。从这个角度来看，维护的难度又增加了。
　　再说说，单元测试存在外部依赖的情况，也就是第一、二点，想要写一个纯粹的无依赖的单元测试往往很困难，比如依赖了数据库，依赖了其他模块，所以很多人在写单元测试时选择依赖一部分资源，比如在本机启动一个数据库。这类所谓的“单元测试”往往很流行，但是对于多人合作的项目，这类测试却经常容易造成混乱。 比如说要在本地读个文件，或者连接某个数据库，其他修改代码的人（或者持续集成系统中）并没有这些东西，所以测试也都没法通过。最后大部分这类测试代码的下场都是用不了、也舍不得删，只好被注释掉，扔在那里。随着开源项目逐渐发展，对外部资源的依赖问题开始可以通过一些测试辅助工具解决，比如使用内存型数据库H2代替连接实际的测试数据库，不过能替代的资源类型始终有限。
　　而实际工作过程中，还有一类难以处理的依赖问题：代码依赖。比如一个对象的方法中调用了其它对象的方法，其它对象又调用了更多对象，最后形成了一个无比巨大的调用树。后来出现了一些mock框架，比如java的JMockit、EasyMock，或者Mockito。利用这类框架可以相对比较轻松的通过mock方式去做假设和验证，相对于之前的方式有了质的飞跃。
　　但是，在这里需要强调一个观点，写单元测试的难易程度跟代码的质量关系最大，并且是决定性的。项目里无论用了哪个测试框架都不能解决代码本身难以测试的问题。
　　简单来说，有时候你觉得你的代码很难写单元测试，说明代码写的不是很好，需要去关注代码的逻辑抽象设计是否合理，一步步去重构你的代码，让你的代码变得容易测试。但这些又属于代码重构方面的知识了，涉及到很多的设计原则。推荐阅读《重构-改善既有代码的设计》《修改代码的艺术》 《敏捷软件开发：原则、模式与实践》这几本著作。
　　1.5 心态的转变
　　很多开发人员对待单元测试，存在心态上的障碍：
　　· 那是测试同学干的事情。（开发人员要做好单元测试
　　· 单元测试代码是多余的。 （汽车的整体功能与各单元部件的测试正常与否是强相关
　　· 单元测试代码不需要维护。 一年半载后，那么几乎处于废弃状态（单元测试代码是需要随着项目开发一直维护的
　　· 单元测试与线上故障没有辩证关系。（好的单元测试能最大限度规避线上故障
　　关于Spock
　　Spock能给你提供整个测试生命周期中可能需要的所有测试工具。它带有内置的模拟打桩，以及专门为集成测试创建的一些额外的测试注释。同时，由于Spock是较新的测试框架，因此它有时间观察现有框架的常见缺陷，并加以解决或提供更优雅的解决方法。


· Spock是Java和Groovy应用程序的测试和规范框架
　　· 测试代码使用基于groovy语言扩展而成的规范说明语言（specification language）
　　· 通过junit runner调用测试，兼容绝大部分junit的运行场景（ide，构建工具，持续集成等）
　　Groovy
　　· 以“扩展JAVA”为目的而设计的JVM语言
　　· JAVA开发者友好
　　· 可以使用java语法与API
　　· 语法精简，表达性强
　　· 典型应用：jenkins, elasticsearch, gradle
　　specification language
　　specification 来源于近期流行起来写的BDD（Behavior-driven development 行为驱动测试）。在TDD的基础上，通过测试来表达代码的行为。通过某种规范说明语言去描述程序“应该”做什么，再通过一个测试框架读取这些描述、并验证应用程序是否符合预期。把需求转化成Given/When/Then的三段式，所以你看到测试框架有这种Given/When/Then三段式语法的，一般来说背后都是BDD思想，比如上图中的Cucumber和JBehave。