技術的なこと

前回はCircle Checkerの紹介だったので、今回は作って学んだことを書こうと思います。

※Circle Checkerの紹介記事はこちらです。

技術的なこと
- 実装の話
- テスト（Spock）の話

実装の話

まずは、

「1時間で作る！」

とか言って始めたのに、プロジェクトの準備に30分かかっていた件ですが、ローカルのgitリポジトリとGitHubのリポジトリを同期するのにコマンドを忘れ、時間がかかったためでした。

GitHub上のLICENSEファイルを使いたかったんです

リモートのGitリポジトリとローカルをマージ

以下が手順のコマンド。

git remote add origin git@github.com:seriwb/circle-checker.git
git fetch origin
git merge origin/master

ただ単に、マージの引数が足りていないだけでした。

便利なDTOの定義方法

Javaではプログラム間でやり取りするデータを扱うクラスをDTOと呼んだりしますが、 DTOは適切なコンストラクタやアクセッサメソッド、equals()、hashCode()の実装がほぼ必須になります。

Groovyではフィールド定義するだけでアクセッサメソッドは用意されますが、他は自前で用意する必要があります。

ですが、@EqualsAndHashCodeアノテーションを付けると、equals()とhashCode()の実装が行われ、 @TupleConstructorアノテーションを付けると、クラスフィールドの数に応じたパラメータを持つコンストラクタが利用できるようになります。

それらを利用してすると、以下のような記述だけでDTOクラスが実装できます。

import groovy.transform.EqualsAndHashCode
import groovy.transform.TupleConstructor

@EqualsAndHashCode
@TupleConstructor
class CircleInfo {

    String twitterName
    String twitterId
    String twitterUrl
}

Twitter APIのカーソリング方法

Twitter APIからカーソル付きの結果を得るときは最初に-1を投げること、とTwitterのAPIドキュメントに記載があるので、 Twitter APIのラッパーであるTwitter4jの当該メソッドを利用する場合も、-1相当の値（long型なので-1L）を設定して呼び出す必要があります。

Circle Checkerで該当する実装箇所は、以下などです。

https://github.com/seriwb/circle-checker/blob/master/src/main/groovy/box/white/cc/CircleChecker.groovy#L156

クロージャ内での正規表現チェック

クロージャに渡った値をそのままクロージャ内の正規表現の一部に利用する場合は、ダブルクォートで囲まれた文字列のときと同様に、$を先頭につけるだけで使えました。

def checkStr = "ああああiiiiうううう"

def filterList = ["aaaa", "iiii", "uuuu"]
filterList.each {
    if (checkStr =~ /.*$it.*/) {
        println(it)
        return
    }
}

※ each内でのreturnはeachを抜けるだけで、後続処理は継続されます

AccessTokenのクリアの仕方

AccessTokenオブジェクトのtokenとtokenSecretをnullに設定したもAccessTokenの設定がクリアできるわけではなく、以下の例外は発生します。

java.lang.IllegalStateException: Access token already available.

Twitter4jでAccessTokenをクリアするには、Twitter#setOAuthAccessTokenでnullをセットするのが正しい方法になります。

落ち穂

私がGroovyなのに型をわざわざ宣言しているのは、見返したときに何に利用しようとしていたかを確認するためと、IDEの補完を有効にするためです。

最初はdefで宣言してざっくりコードを書いて、後々型宣言に修正するという書き方を良くしています。

テスト（Spock）の話

過去にJUnitの記事を書いたように、業務ではJUnitでテストを書くことが多かったのですが、

個人的にJava/GroovyのテストフレームワークはSpockに期待を寄せています。

洋書のJava Testing with Spock買って読んだりたりしていたわりには、今まで実用レベルのテストをSpockで書いていなかったので、今回はMock/Spyの両機能を使ったテストコードを書いてみました。

Gradleの設定

GradleプロジェクトでSpockを利用するために、以下をbuild.gradleの依存関係に追加しますが、 Spockでテストを書くだけであれば、spock-coreだけで大丈夫です。クラスをモックしたコードを書く場合は、cglibとobjenesisも必要になります。

testCompile "org.spockframework:spock-core:1.1-groovy-2.4"
testCompile group: 'cglib', name: 'cglib-nodep', version: '3.2.5'
testCompile group: 'org.objenesis', name: 'objenesis', version: '2.5.1'

モックとスタブ

モッククラスを作るのはとても簡単で、以下の2通りで宣言できます。
（モック対象のクラスをUserとして、モッククラスuserを宣言する場合）

def user = Mock(User)
User user = Mock()

モッククラスのメソッドにスタブさせる場合は、当該メソッドに対し、>>演算子を使って返却値を定義してあげるだけです。

user.getName() >> "ダミー名"

実際にモッククラスを使ってテストを実行している例は、以下になります。

   def "フィルタにある名前の結果のみが返却されることを確認"() {
     setup:
        List<String> filterList = ["ああ","uu"]

        def user = Mock(User)
        user.getName() >> name
        user.getScreenName() >> screenName
        user.getURL() >> url

        def file = '''
cc.target.list = "listname"
cc.html.dir = "./dir"
cc.tweet.maxcount = 100
cc.loop.waittime = 600
'''
        def config = new ConfigSlurper().parse(file)

        def testSuite = new CircleChecker(config)
        testSuite.filterList = filterList

     expect:
        testSuite.checkUserName(user) == expected

     where:
        name | screenName | url               | expected
        "ああああ" | "aaaa" | "http://aaaa.com" | new CircleInfo("ああああ", "aaaa", "http://aaaa.com")
        "いいいい" | "iiii" | "http://iiii.com" | new CircleInfo()
        "aaiiuu" | "uuuu" | null              | new CircleInfo("aaiiuu", "uuuu", "")
    }

参照元：circle-checker/CircleChecker_CheckUserNameSpec.groovy at master · seriwb/circle-checker · GitHub

setupでテスト実施までの処理を記載し、expectにはテストで確認したい比較条件のみを記載します。また、複数のパラメータでテストを流すために、whereにそれぞれ動的に変更するパラメータを定義することができます。記述順的に直感的ではないですが、whereで宣言しているパラメータはsetupやexpectでも使えます。

抽象メソッドの実装

後テストでよく必要になるのは、抽象メソッドを持つクラスのインスタンス化ではないでしょうか。

これはGroovyで実現できます。

例えば、Twitter4jのRateLimitStatusクラスに存在するgetRemaining、getLimit、getResetTimeInSeconds、getSecondsUntilResetを適当な処理（呼ばれたら1を返す）で実装してインスタンス化する場合は、以下のようになります。

def status = [
 getRemaining: { -> 1 },
 getLimit: { -> 1 },
 getResetTimeInSeconds: { -> 1 },
 getSecondsUntilReset: { -> 1 },
] as RateLimitStatus

テスト対象クラスの一部をスタブ化

そして後はテスト対象クラスの一部をスタブ化できれば、大抵のテストは書けるようになるのかと思います。

Mockではインスタンス化したクラスのメソッドが全て実態のないものになっているので、Spyを使ってインスタンス化します。

以下は、PagableResponseListImpl#hasNext()を1度目はtrueを返し、それ以降はfalseを返すようにする実装です。

def users = Spy(PagableResponseListImpl, constructorArgs: [status, 1])
users.hasNext() >>> [true, false]

参照元： https://github.com/seriwb/circle-checker/blob/master/src/test/groovy/box/white/cc/CircleChecker_CheckFollowSpec.groovy

スタブの書き方は他にも色々あるので、実装時は以下などを参考にしてみてください。

また、MockとSpyの使い分けはこちらのサイトが参考になるかと思います。

@Unroll

Spockのパラメータテストの結果は、デフォルトではまとめて1テストとして出力されます。

これを各条件ごとに出力させるためには、@Unrollアノテーションをクラスかメソッドに対して付ける必要があります。
（基本は必要なメソッドに対して付けるのが良いかと思います）

@Unrollを付けていない場合、比較条件によってはエラー時にどの条件がダメだったのかがわからないので、パラメータテストを行うメソッドには付与しておくことをお奨めします。

テストスイート

SpockにJUnitでいうところのテストスイートのような仕組みはないのですが、 Gradleでspock-coreを取り込むと、JUnitも依存ライブラリとして追加されます。

そこでJUnitでの書き方をGroovyにアレンジして、以下のようにすると、Spockでもテストスイートが実現できます。

import org.junit.runner.RunWith
import org.junit.runners.Suite
import org.junit.runners.Suite.SuiteClasses

@RunWith(Suite)
@Suite.SuiteClasses([
    CircleChecker_CheckUserNameSpec,
    CircleChecker_CheckFollowSpec,
])

class CircleCheckerSpecSuite {
}

今回はクラス名の末尾をSpecSuiteとしましたが、いつもならAllSpecにしていたかと思います。
末尾を統一させるか、末尾を分けて目立たせるかの違いですが、好きな方でいいと思います。

テストスイートのクラスを追加した場合は、テスト数が重複して計上されないように、当該クラスをtestタスクの対象外にしておきましょう。

build.gradleに以下の記述を追加してください（include/excludeは必要なものだけでOK）。

test {
    include '**/*Test*'
    include '**/*Spec*'
    exclude '**/*TestSuite*'
    exclude '**/*SpecSuite*'
    exclude '**/*AllTest*'
    exclude '**/*AllSpec*'
}

Spockでテストを書こう！

Spockのテストコードはどうでしたか？
過去にJUnitでモック処理を書いたり、パラメータテストを書いたことがある方であれば、魅力を感じてもらえるのではないかと思います。

とはいえ、ここまで単純化できているのは、テスト対象クラスのフィールドがGroovyらしくpublicになっているから、といいますか、 protectedのメソッドでも普通に直アクセスできるからなのですが。
この振る舞いは色々議論があるでしょうが、私としてはアクセス識別子はマーカー識別子くらいの認識なので、プログラミングする上でアクセス識別子の考え方が頭に入っていれば、この動作でも問題ないと思っています。ただ、プログラミング初学者などにはもしかしたら良くないのかもしれないなぁとも思ったりします。ですが、Groovyを使う人でJavaを経験してこなかった人がどれだけいるのかと考えると、この件はただの杞憂ではないかなと。

極力単純に、かつ少ないコード量でのプログラミングするためのツールとして、Spockを使ってみるのはどうでしょうか？

White Box技術部

WEB開発のあれこれ（と何か）

Circle Checker作りで学んだこと（GroovyとかSpockでのモックの書き方とか）