spock

細かい説明は省きますが、setup cleanup がいくつかと、where というテストデータ定義をする箇所があります

結論をさっと
表と絵で

定義	タイミング	備考
setupSpec	テスト [クラス] の最初で [一回] 動く	static 相当
setup	テスト [データ] [ごと] に最初に動く
cleanup	テスト [データ] [ごと] に最後に動く
cleanupSpec	テスト [クラス] の最後で [一回] 動く	static 相当
where	テスト [メソッド] の最初で [データ分] 動く	static 相当

緑字が static で赤字がそれ以外です、左から読んでね

で、何が問題になるの

大きく２つ

static

static 相当なので、例えば@Autowiredしてる変数とかを使った初期化処理はsetupSpec/cleanupSpecでは呼べない

whereからも使えない

やりがちなので注意

実行順

多いのがこっち

特に多いのが now とかを絡めたテストデータの作成において、思った通りのテストデータが作られなくてテストがこけるケース

例えばsetupにシステムクロックの改ざんをするようなコードを書いておいて、whereで now を含むテストデータを作ってパターンテストした場合、
テストデータを作ってからシステムクロックの改ざんという順番になるので、期待通りにならない

その場合はセットアップをsetupSpecに移動しよう

セットアップが static 処理内で行えない場合は、例えばwhere側のデータを{}で囲ってexpect側で()をつけたりすると実行を遅延させられるけど、
テストコードでテクいことをやりたくなる場合は 大抵の場合プロダクトコード(= 設計) がおかしいので、素直にリファクタしよう

さくっとおしまいﾉｼ

おまけ　実行順のところで挙げた例のコードイメージ

これだとmkData() -> setClock()の順で動く

def setup() {
    setClock()
}

def test() {
    expect:
    sut.f(data) == exp

    where:
    data     || exp
    mkData() || ...
}

こうするか、

def setupSpec() {
    setClock()
}

def test() {
    expect:
    sut.f(data) == exp

    where:
    data     || exp
    mkData() || ...
}

こうするとsetClock() -> mkData()の順で動く

def setup() {
    setClock()
}

def test() {
    expect:
    sut.f(data()) == exp

    where:
    data         || exp
    { mkData() } || ...
}

ただ、例えば now に関してはsut.f内部で生成するより引数で渡して揚げる方がずっとテストしやすいので、既存の作りを見直すのに立ち戻った方が良い

def test() {
    expect:
    sut.f(data, date(2020, 3, 1)) == exp

    where:
    data     || exp
    mkData() || ...
}