『JUnit実践入門』写経・実践会 in 横浜 #2 に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #2
http://connpass.com/event/1557/

2013/01/12 『JUnit実践入門』写経・実践会 in 横浜 #2 #junitbook
http://togetter.com/li/437795

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #1 に参加してきました。 #junitbook

前回に引き続き参加して来ました。
今回は、「Part.2 JUnitの機能と拡張」が対象でした。
初めの方の参加条件として写経のレポジトリを登録するというのがあったので、
年末にやってみましたが第8章までしか出来ませんでした。
出来れば全てこなしたかったので、残念です。

写経のレポジトリはこちら→https://github.com/grimrose/junit-boost-camp

JUnit Boost Camp

第6章のディスカッションの時にうまく説明出来なかったので、この場を借りて言いたかった事を説明してみます。

対象のクラスのメソッドに対するテストと対象のクラスの状態をテストするためのテストが混ざっているような場合があると思います。
そんな場合@Enclosedを使うことで、テストを構造化出来るようになりました。
static classにすることで、明示的にお互いに依存しないように記述出来るようになります。
例えば、JUnit4.xの形式で書かれていたテストを構造化するのであれば、以下のような手順で出来ます。

• 「@RunWith(Enclosed.class)」を追加する。(import句も)
• 「public static class コンテキストの名称など {}」を追加する。
• 内容をそのままstatic classに移動する。

このように新しいstatic classを作ってテストを追加することで、今までのテストも構造化することが出来ます。
新しいフィクスチャが必要になった場合も、新しいメソッドに対してテストを追加する場合も、必要に応じて追加することが出来ます。

JUnit3.xの場合は、TestCaseを継承しただけのテストであれば、setUpとtearDownなどをそれぞれ修正することで対応出来ますが、TestCaseを継承したテスト用の基底クラスを使っている場合は、いろいろと対応しなければならないことが多いので、優先順位とコストなどで判断してください。

もくもくと

後半はGroovyで書かれたテストにJUnitとSpockが同居することが出来るのか試してみました。
参考にさせて頂いたのは、@irofさんのこちらの記事です。→GroovyでJUnitなテストを書くときの注意点……なんて無かった #gadvent2012
同居させるために、Spockのversionを0.6から1.0へ上げました。
0.6では出来ないということに気づいたのは終盤だったので、ちょっと勿体無かったです。

おわりに

今回は、対象範囲が広かった為か終盤はスタミナ切れしてました。
次回は、適度につまめるような何かしらスイーツを用意して見たいと思います。

一番の収穫としては現場でも使えそうな@Ruleや@RunWith(Categories.class)を知ることが出来たので、活かして行きたいと思います。

主催の@shinyaa31さん、参加者の皆様、横浜タネマキさんありがとうございました。
次回もよろしくお願いします。