JUnit 強化キャンプに参加してきた #junitbc

勉強会 JUnit Testing


(写真：会場となった某漫画喫茶個室内に映し出される実践映像を眺める参加者一同)

私自身、勉強会に於いてテスト関連のイベントには参加しつつも(TDDBC等)、そこから先テストに於いて諸々を(Bootからの次の段階である)ブースト(Boost)出来ていなかったので、このイベントを見つけ次第『これは！』と思い参加してきました。

会場はまんがねっとラウム新宿本店。

自身としては、漫画喫茶で勉強会やるってのは初めてだったので、『(諸々)どうなんだろう？』という気持ちがありましたが、実際やってみると殊の外快適で"これは良い"という感じでしたね。ネット回線(立地上の問題で時々調子が悪い時があった)や部屋に対する定員を上手く調整すれば、利用場所としてはかな〜り良いものになるのではないでしょうか。いざとなったら休憩・食事も出来るし、気分転換に漫画も読めるし(笑)


イベント進行自体は、主催者であるShuji Watanabe(TwitterID:@shuji_w6e)さんが予め用意していたお題について各参加者が投票し、結果上位のものから順次解説／実演を行っていくというスタイルで時間(＝和田さん(TwitterID:@t_wada)夫妻の結婚式2次会に参加される方々が参加の為に移動する)まで続きました。

以下、実施順に取ったメモや復習がてら写経したソースコード、関連Web資料等を。

JUnit基礎 with TDD

// 1.セットアップ
：
// 2.テストの実行
：
// 3.検証
：
// 4.後始末 ※基本的に無し
  • 1.セットアップ
    • ヘビーになることが多い。どう圧縮するかがキー。
    • せとさん(@setoazusa)『fixtureのセットアップ超重要』at tddカンファレンス
    • 1個のテストケースの中では、テスト実行は1個にする。鉄則。
    • コメントは、テストコードの実装行が増えて来ると視認度的にも効果がある
    • 全体でも10行くらいに収める
  • 2.テスト実装
    • 内部状態を減らす：その方がテストはし易い。
    • staticで実装しちゃえば？→オブジェクト設計的にはう〜んな感じ
    • なるべく状態を管理するようなオブジェクトは1箇所で管理するような設計が好ましい。

Groovy

  • Eclipseの場合：プラグイン導入要
    • Groovy - Eclipse Plugin
    • 基本的にはJavaのクラスそのままで行ける／Groovy流に大幅省略可能
    • 文法的にはメソッド内の最後の処理が評価され、リターンされる
      • 引数と戻り値は省略可。だけど個人的には書く方向が多い。
    • テストクラスの作成：これもJavaクラスをほぼそのまま使える。
    • ※QuickJUnitが効かない。要注意。
    • チェック例外が無くなる：throws Exceptionが消せる。
    • オブジェクトを返さない場合は明示的に void add〜() {}
  • Groovyではテストメソッド名に文字列を使える！→即ち、小数点、カンマも使える。これは地味に嬉しい。
    public void "メソッド名に小数点0.01とかカンマ(,)も普通に使えますよ"() {
        Calculator sut = new Calculator();
        assertThat(sut.current, is(0));
    }
  • Groovyのコード、実行時はGroovyのライブラリが入っていればどっちでも動く。Javaとの混在OK
  • Groovyは慣れるまでは分かり易いところだけ使うでもOK

JenkinsCI

  • 独立したビルドサーバ
  • 諸々の作業を自動化（自働化）しよう、という流れ
  • 最近はJenkins一択になりつつある、Javaだけでなく様々な言語でも利用可能
  • スタンドアロンで起動可能
  • 『昔は生き別れのhudsonという兄が居た』
  • プラグインを使うと拡張が可能
  • Mavenプロジェクトにしてしまう事が一番てっとり早い
    • mavenでgroovyを動かすのはちょっと面倒
    • Convert MavenプロジェクトでPOMを作成（以下の2点が変更となる）
      • フォルダ構成が変更される
      • POMファイルが作られる
    • POMファイル：dependencyで依存ファイルを追加
      • junitとかも探して追加出来る
    • バージョン管理システムと連携：(実演ではmercurialにて連携)
  • 新規ジョブ作成：
    • フリー：一番汎用的。
    • maven→フリーへのプロジェクト変更は出来ない。(逆は出来るので)フリーを選ぼう
    • リポジトリを設定
    • ビルド・トリガの設定
  • jenkins自体はそんな難しくない。(Mavenとの連携の場合)むしろMavenの使い方を覚える方が難しい。

JUnit拡張機能：パラメータ化テストについて

  • パラメータ化テスト、という考え方
Parameterizedを用いる

JUnit in Action

JUnit in Action

Theoriesを用いる

以下のアノテーションを利用。

@RunWith（Theories.class）
@Theory（@Testの変わり）
@Datapointというアノテーションを持ったpublic フィールドを定義。@Datapoints という形式で、配列としても使う事が可能。
  • Q.引数とdatapoint(s)の紐付はどうなってるの？
    • 基本的に全組み合わせ。「Int x, String y」とあり、{1,"A"},{2,"B"}とあった場合は計4パターン全網羅。
    • int x, int yの場合でも全組み合わせを網羅。（1つの配列を使い回して）
    • 意図的な組み合わせのパターンを用いたい場合は、Fixtureクラスを用意して実施すると良い。
static class Fixture {	
    int x:
    private final int expected;
    Fixture(int x, int expected) {
        this.x = x;
        this.expected = expected;
    }
}

JUnit拡張機能：Enclosed

JUnit拡張機能：Rule

JUnit拡張機能：Testerクラス

  • Testerクラスをルール（アノテーション）で作る。
  • JUnit3ベースで、継承ベースで書かれているクラス。良いときも悪いときもある。外に出したい。

JUnit拡張機能：Mockito

Android

  • javaのコードだけどバイトコードはAndroidカスタマイズ
  • androidのテストをする場合、アンドロイド上のエミュレータで動かさないと行けない。
  • 別のプロジェクト（android非依存）を作成し、テスト→androidに取り込むと吉
  • サービス・モデル部分のプロジェクトと実プロジェクトを分けて作成
  • GUIアプリのテスト：MVCで作っておき、テストはjarで分ける。エミュレータの実行などは遅くてサクサク作れない。モックも使いづらい
  • エミュレータでテストした方が良い
  • JUnitでのテスト･･ユニットテストでは無い？
    • 流れでテストしないと、そもそも意味が無い。
    • 個々のテストをやっても良いけど･･･コストは相当無駄になる

その他


…と言った感じで、時間一杯まで中身の濃い〜〜講義・解説が続いていたのでありました。実際時間内では内容の全てを把握する事は間に合わず、こうしてエントリとしてまとめるのにも一苦労するクオリティ。(結局超ざっくりベースでリンク集などまとめるに留まってしまった…^^;) 調べていく過程でも、殆ど日本語の関連エントリが無かったというパターンも多く(渡辺さん、いろふ(TwitterID:@irof)さん他数名の記事しか見つからなかった)、そういった意味でも今回のイベントは来た甲斐が十分にあったな〜と感じました。

渡辺さん、また当日参加された皆様、ありがとうございました！

渡辺さん等が和田さん結婚式2次会に行ってから後は、部屋の有効期限時間までまだ数時間あったので、後は普通の漫画喫茶としておっさん数人が寛いで過ごしたとさ。

以上、おしまい。(ふぅ…イベント開催から1週間以上エントリ書きに掛かってしまった。)


その他関連：