@Title("向指定账号存款")
class DepositSpec extends Specification {
def "向A账号存入100元"() {
given: "A账号余额10元"
Account account = new Account()
account.balance = 10
when: "向A账号存入100元"
account.deposit(100)
then: "A账号余额为110元""
account.balance == 110
Cucumber与Spock实现的简单比较
从上面的示例代码可以知，Cucumber与Spock都同样以一个Feature作为开始。但不同于Cucumber自动将Feature转译为Step，再与相应的测试代码或者业务代码粘合，Spock直接通过手工编码实现从Feature到测试代码的映射，因此相应减少了这个转译的环节。
这种区别，正是我目前非常纠结的。在《BDD in Action》一书中，作者在使用Cucumber定义了Then Step断言的情况下，又提到要使用JUnit等框架编写更细粒度的单元测试。于是，我就产生了这样的疑惑：『Step断言的粒度与单元测试断言的粒度，应该如何划分？这样的重复有必要吗？』特别是象上面的示例一样，Spock也能『自描述』Specification时。
要回答这个问题，我认为仅仅依靠《BDD in Action》中那些不完整的示例，还是比较困难的。所以我会在读完下一本书——《The Cucumber for Java Book》之后，再回头来看看是不是我对Cucumber有误解。
4-7更新
文章发表后，我和朋友们当晚就围绕我的困惑进行了讨论。终于在清晨起床的时候，突然恍然大悟。Cucumber关注的更多的是验收测试这个层面的东西，而JUnit关注的则是更细碎的单元测试层面的东西。二者关注的角度、粒度和要解决的问题都不同。所以《BDD in Action》作者提到的Cucumber+Spock的方法并没有什么不妥。当然，Spock也能胜任从单元测试、集成测试到验收测试的所有工作，所以仅仅使用Spock也未尝不可。归根结底，只是一个工具选择的问题。
使用Spock的代价
因为Cucumber有着对应不同编程语言的版本，比如Cucumber for Java， SpecFlow for .NET，因此能与团队选择的开发语言无缝衔接。反观Spock，尽管它支持Java混编，但其语法仍依赖于Groovy，因此增加了相应的学习成本，而且在工程实施过程中进行多语言的混合编程。
对此，需要提醒的是，Spock只用到了Groovy的极小部分语言特性，因此学习代价并不算很大。在业余时间照着《Java Testing with Spock》边看边做，我也只用了一周多点的时间。反倒是如何写好Feature文件，并从中筛选出Key Example，成了我最大的困扰。
至于编写好的测试，由于Cucumber与Spock都与Java兼容，因此可以直接在JUnit Runner上进行。测试报告的生成亦是如此，既可以使用JUnit辅助工具生成测试报告，也可以使用其专用的Spock Reports、Damage Control等等。
Spock入门
Groovy语法基础
Groovy和Scala一样，也是一种基于Java实现的编程语言。区别于Scala的，Groovy是动态语言。学会Spock的常见功能，只需掌握Groovy以下语法即可。
语句结束用的分号;，和Scala一样是可选的。
Groovy将一切视作对象，==将直接调用对象的equals()方法，这与Scala同出一辙。
通常用一对双引号表示一个字符串常量，"这是一个字符串常量"，使用\作为转义符。
用一对单引号表示不用转义其中的任何字符，类似C#里的@。
用成对的3个单引号或双引号表示一个保留换行格式的多行字符串，用\表示其中的换行符。这种方式通常用作大段的描述文本，比如'''这是保留了换行、缩进的RAW字符串常量'''。
int、float等表示数字类型，使用方法类似Java，比如1.002f。
Groovy将0、null、空的数组或空字符串视为false，非0值、有效的引用、非空的数组和非空的字符串则均视为true。
使用关键字def表示动态类型，类似C#里的dynamic。
类的访问修饰与Scala一样，默认都是public，而field默认是private。
使用$作为字符串插入符，必要时使用一对大括号包围插入值，类似C# 6.0，比如return "$name, ${age > 18}"。
对象初始化方式类似JSON，整个表达式用圆括号包围，field与值以冒号间隔、成对出现，数组或序列用中括号包围，数组索引从0开始，用[:]表示一个空的Map
闭包、lambda或者匿名函数使用大括号包围，和Scala一样，比如{count -> count * 10}。
使用_作为参数占位符，使用方法大致同Scala。它既可以用来指代参数、方法，也可以指代返回值或者where块中的测试参数。
Spock测试的基本结构
Spock的测试类均派生自Specification，命名遵循Java规范。每个测试方法可以直接用文本作为方法名，方法内部由given-when-then的三段式块（block）组成。除此以外，还有and、where、expect等几种不同的块。
@Title("测试的标题")
@Narrative("""关于测试的大段文本描述""")
@Subject(Adder) //标明被测试的类是Adder
@Stepwise //当测试方法间存在依赖关系时，标明测试方法将严格按照其在源代码中声明的顺序执行
class TestCaseClass extends Specification {
@Shared //在测试方法之间共享的数据
SomeClass sharedObj
def setupSpec() {
//TODO: 设置每个测试类的环境
def setup() {
//TODO: 设置每个测试方法的环境，每个测试方法执行一次
@Ignore("忽略这个测试方法")
@Issue(["问题#23","问题#34"])
def "测试方法1" () {
given: "给定一个前置条件"
//TODO: code here
and: "其他前置条件"
expect: "随处可用的断言"
//TODO: code here
when: "当发生一个特定的事件"
//TODO: code here
and: "其他的触发条件"
then: "产生的后置结果"
//TODO: code here
and: "同时产生的其他结果"
where: "不是必需的测试数据"
input1 | input2 || output
... | ... || ...
@IgnoreRest //只测试这个方法，而忽略所有其他方法
@Timeout(value = 50, unit = TimeUnit.MILLISECONDS) // 设置测试方法的超时时间，默认单位为秒
def "测试方法2"() {
//TODO: code here
def cleanup() {
//TODO: 清理每个测试方法的环境，每个测试方法执行一次
def cleanupSepc() {
//TODO: 清理每个测试类的环境
在then块里，不需要assertEquals("断言提示", left, right)这样的方式，直接写left == right这样的逻辑表达式即可。
借助Groovy的语法，Spock使用N * method()来判定该方法是否被调用了N次。而N * method() >> true则表示方法method被调用N次，且每次该方法的返回值均为true。
用thrown(异常类型)断言会抛出指定类型的异常，notThrown(异常类型)则反之。
参数化测试
Spock使用where块，为测试方法提供表格化的测试数据。其中表头为测试方法中要用在断言中的变量名称或者表达式，用|分隔输入参数，用||分隔输入与输出。这些参数，可以用#参数名的方式在@Unroll描述或者测试方法名里定义，或者在测试方法的参数列表里定义，然后在where块中使用。
@Unroll("test #para0, #para1") //where块中的每行参数都转换为一个独立的测试用例
def "测试方法3 #para2, #para3"(int first, int second) {
... ...
where: "parameterized sample"
para0 | para1 | para2 || para3 | first | second
10 | 2 | 3 || 7 | 2 | 5
除以上这种表格式的数据，Groovy支持<<和<<<操作符作为输入源，用>>操作符指示输出，还有类似Scala的1 .. 10这样生成序列的语法。
array << [0, 5, 7, 9]
list << (1 .. 10)
[name, condition] << [["Jack", true], ["Tom", false]]
isConfirmed() >> true
getAnswers() >>> [1, 2, 5, 7] //顺次返回列表里的值
isAvailable(_) >>> true >> false //首次返回true，第2次返回false
Stub与Mock
Spock提供Stub与Mock功能，主要应用于单元测试。其使用很简单，直接Stub(类或接口)或Mock(类或接口)即可。
given: "preparation"
Inventory inventory = Stub(Inventory) {
location >> "LOS"
manager >> "Tom"
DeliveryProcessor processor = Mock(DeliveryProcessor)
when: "one order is confirmed"
order.Confirm()
then: "only serviceA is called"
1 * processor.serviceA(_)
0 * processor._
原则上，任何的Stub都可以用Mock代替，反之而不尽然。因为Stub是辅助测试的工具，它模拟或者说伪装成一个真正的对象，为测试提供一个完整的环境（输入）；而Mock才是验证对象行为的工具，虽然它也是对象的一个假体，但其目的是确定对象是否按正常预期工作（输出）。
Maven配置
加入Groovy支持
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<configuration>
<useFile>false</useFile>
<includes>
<include>**/*Spec.java</include>
<include>**/*Test.java</include>
</includes>
</configuration>
</plugin>
加入Spock支持
<dependency>
<groupId>org.spockframework</groupId>
<artifactId>spock-core</artifactId>
<version>1.0-groovy-2.4</version>
<scope>test</scope>
</dependency>
<dependency> <!-- enables mocking of classes
(in addition to interfaces) -->
<groupId>cglib</groupId>
<artifactId>cglib-nodep</artifactId>
<version>3.1</version>
<scope>test</scope>
</dependency>
<dependency> <!-- enables mocking of classes without default
constructor (together with CGLIB) -->
<groupId>org.objenesis</groupId>
<artifactId>objenesis</artifactId>
<version>2.1</version>
<scope>test</scope>
</dependency>
在该书的最后一部分，作者就Spock在企业应用开发领域进行规模化应用进行了较为详尽的阐述，包括如何组织Spock测试，如何与Maven集成，如何协调单元测试、集成测试和功能测试，如何使用Geb和REST工具辅助测试等等。在附录中，也详细介绍了Spock如何与Eclipse等常见IDE进行集成。有兴趣的，可以读一读这本书。
基于Groovy动态语言的强大功能，Spock框架仍在不断发展，因此这篇书摘意义的文章只算是管中窥豹。特别是在具体实践BDD的过程中，究竟是仅靠Spock，亦或Cucumber+Spock的方式，都是需要通过学习和实践来确认的。
转载请注明出处及作者，谢谢！
