这是Spock系列的第一篇文章，整个专辑会介绍Spock的用途，为什么使用Spock？它能给我们带来什么好处？它和JUnit、JMock、Mockito有什么区别？我们平时写单元测试代码的常见问题和痛点，Spock又是如何解决的，Spock的代码怎么编写以及Spock的优势和缺点等内容，让大家对Spock有个客观的了解。
Spock是什么？
斯波克是国外一款优秀的测试框架，基于BDD思想，功能强大，能够让我们的测试代码规范化，结构层次清晰，结合groovy动态语言的特点以及自身提供的各种标签让编写测试代码更加高效和简洁，提供一种通用、简单、结构化的描述语言引用官网的介绍如下(http://spockframework.org)“ Spock是一个Java和Groovy应用程序的测试和规范框架。它之所以能在人群中脱颖而出，是因为它优美而富有表现力的规范语言。斯波克的灵感来自JUnit、RSpec、jMock、Mockito、Groovy、Scala、Vulcans ”
- 让我们的测试代码更规范，内置多种标签来规范单测代码的语义，从而让我们的测试代码结构清晰，更具可读性，降低后期维护难度
- 提供多种标签，比如: where、with、thrown... 帮助我们应对复杂的测试场景
- 再加上使用groovy这种动态语言来编写测试代码，可以让我们编写的测试代码更简洁，适合敏捷开发，提高编写单测代码的效率
- 遵从BDD行为驱动开发模式，不单是为了测试覆盖率而测试，有助于提升代码质量
为什么使用Spock? Spock和JUnit、JMock、Mockito的区别在哪里？现有的单测框架比如junit、jmock、mockito都是相对独立的工具，只是针对不同的业务场景提供特定的解决方案。微服务已经是互联网公司的主流技术架构，大部分的系统都是分布式，服务与服务之间一般通过接口的方式交互，甚至服务内部也划分成多个module，很多业务功能需要依赖底层接口返回的数据才能继续剩下的流程，或者从数据库/Redis等存储设备上获取，或是从配置中心的某个配置获取。这样就导致如果我们想要测试代码逻辑是否正确，就必须把这些依赖项(接口、Redis、DB、配置中心...)给mock掉。如果接口不稳定或有问题则会影响我们代码的正常测试，所以我们要把调用接口的地方给模拟掉，让它返回指定的结果(提前准备好的数据)，这样才能往下验证我们自己的代码是否正确，符合预期逻辑和结果。JMock或Mockito虽然提供了mock功能，可以把接口等依赖屏蔽掉，但不提供对静态类静态方法的mock，PowerMock或Jmockit虽然提供静态类和方法的mock，但它们之间需要整合(junit+mockito+powermock)，语法繁琐，而且这些工具并没有告诉你“单元测试代码到底应该怎么写？”工具多了也会导致不同的人写出的单元测试代码五花八门，风格迥异。。。Spock通过提供规范描述，定义多种标签(given、when、then、where等)去描述代码“应该做什么”，输入条件是什么，输出是否符合预期，从语义层面规范代码的编写。Spock自带Mock功能，使用简单方便(也支持扩展其他mock框架，比如power mock)，再加上groovy动态语言的强大语法，能写出简洁高效的测试代码，同时更方便直观的验证业务代码行为流转，增强我们对代码执行逻辑的可控性。下一篇文章会详细讲解我们平时在编写单元测试代码过程中遇到的痛点，并结合实际的代码案例来说明Spock是如何解决这些问题的。比如单测开发的效率和成本问题，可读性以及后期维护的问题，单测如何提升业务代码质量等。网上关于Spock的资料比较简单，包括官网的demo，无法解决我们项目中的复杂业务场景，需要找到一套适合自己项目的成熟解决方案，所以觉得有必要把我们项目中使用Spock的经验分享出来, 帮助大家提升单测开发的效率和验证代码质量。在熟练掌握Spock后我们项目组整体的单测开发效率提升了50%以上，代码可读性和维护性都得到了改善和提升。写Java单元测试的开发小伙伴和测试同学，所有的演示代码运行在IntelliJ IDEA中，spring-boot项目，基于Spock 1.3-groovy-2.5版本
