Spockとは？

• Spockは、BDD（Behavior-Driven Development）フレームワークです。
• TDDフレームワークであるJUnitと似ているところが多く、期待する動作やテストの意図をより明確にする拡散コードは後で隠してくれるなど、大きな利点があります。

既存のJUnitの欠点

• テストの重複コードが多い
• JUnit、Hamcrest、Mockitoをすべて理解した上で、コードを理解することができる

Spockのセッティング

このようにGradleやMavenに宣言をしてGroovyファイルを作成した後、Specificationクラスを継承するとSpockを使うことができます。

Spockの構成

Spock公式文書では、6つのライフサイクルを紹介しています。

setupとcleanupは、それぞれJUnitにおける@before、@afterに該当する機能を持っています。

whenはテスト対象のコードを実行します。
thenはテスト対象のコード結果を検証する際にassert文が別途必要なく、ブロックの範囲では1行1行が自動的にassertになります。

expectはwhenとthenを合わせたもので、簡単な検証に適しています。
whereでは、expectやwhenでテストするコードの変数を|で区切って並べることができます。

JUnitで同じテストを作成する場合、上記のように重複コードが多く発生することになります。

Mock

テスト時によく使用されるMockingもSpockで簡単に処理できます。
givenブロックの最初の行のように簡単にMockingができ、戻り値は、>>で指定することができます。

例外処理が必要な場合は、上記のように作成できます。

BeanのMocking

Spockを用いるにしても、SpringのBeanをMockingするMockito方式を使用する必要があります。
しかしこの場合、Groovy言語の特性上、Overloading MethodをMockingする際にどのようなメソッドをMockingすべきか選択できず、Mockingエラーでテストが失敗します。

その場合は、Spockで提供されるDetachedMockFactoryファクトリを通じたMock生成を用いてBeanのMock生成が可能となります。しかしこの場合にも問題があり、JpaRepositoryの場合はMockingされません。
そのためJpaRepositoryインターフェースでMockingが必要な場合、JunitまたはSpockでMockitoを使用しなければなりません。

まとめ

Spockが私にとって不慣れなGroovy言語を使用しているにも関わらず、実際には大きく異なる部分は見つからず、言語の問題よりもテストコードが便利に作成できる利点を大きく感じました。
自分にもなじみがあり、これまでたくさん接してきたJUnitと比較すると、Spockが持つ強みは検証文での利便性もありますが、最も良かった部分は、whereブロックによるコードの重複の最小化でした。従来のテストでは1つのプロセスに対してさまざまなケースでテストを行うことになりますが、その場合はコードの重複を確実に減らすことのできるSpockを使用すると良いようです。
欠点としては、BeanをMockingする部分でMockingが正常に行われず、調査に苦しみ解決できなかった部分もあるため、確実に理解できるまではJUnitを使用した方が安定的だと思われます。