2013年8月26日月曜日

最強モックツール JMockit その2 インストール編

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はモックツール「JMockit」をご紹介しています。
今回はインストールと動作確認まで行ってみましょう。

ダウンロード&インストール

まずはJUnit本体のダウロードです。

何度も書いていますが、Eclipseの標準JUnitだと不足がありますので、自前でJUnitセットをダウンロードして下さい。


次にJMockitをダウンロードします。
この記事を執筆している現時点での最新は1.4です。


ダウンロードしたzipファイルを解凍すると「jmockit.jar」と「jmockit-coverage.jar」の二つのjarファイルがあります。
それぞれ、jmockit本体とカバレッジ出力ツールです。

今回の連載ではカバレッジも紹介しますので、両方とも導入しましょう。

ダウンロードしたら、これら全部をEclipseのクラスパスに入れて完了。
単にjarファイルを導入するだけの簡単な作業です。


では無いんですよね!!


何と、jmockitは「クラスパスをJUnit本体より先にしなければならない」という制約があります。

普通の開発ではクラスパスの順番など意識しないと思いますが、今回は違います。
Javaのプロジェクトに複数のjarファイルを導入する際、異なるjarファイル間で同じクラスが存在していた場合は、先に書いた方のjarファイルの方が優先されます。

つまり、jmockitはJUnit本体より先にクラスパスを書いて、JUnit本体の一部を潰して機能を実現しているわけです。
導入段階から早くも黒魔術です。

Eclipseの場合、プロジェクトのプロパティから「順序およびエクスポート」の画面に進むことでクラスパスの順番を変更出来ます。

私の環境では以下のような状態になりました。



これでセットアップ完了です。

動作確認

次に細かいことは抜きにして、まずは動作確認してみましょう。

本体ソースの方は、以下のようにただ「テスト」という文字列を返すだけのクラスとメソッドを作ります。

public class Sample01 {
 public String doTest() {
  return "テスト";
 }

}

これに対し、jmockitを使って「テスト」という返り値を「モック」に差し替えてみたクラスが以下です。
/**
 *
 */
package jp.co.net.genesis.sample;

import mockit.Mocked;
import mockit.NonStrictExpectations;

import org.junit.Test;

public class Sample01Test {

 /** モック  */
 @Mocked
 private Sample01 mockSample01;

 /**
  * {@link jp.co.net.genesis.sample.Sample01#doTest(java.lang.String[])} のためのテスト・メソッド。
  */
 @Test
 public void testDoTest() {

  new NonStrictExpectations() {{
   mockSample01.doTest(); result = "モック";
        }};

        System.out.println(mockSample01.doTest());

 }

}

ひとまず実行してみて下さい。
「モック」という文字になったかと思います。
これでjmockitの動作確認が出来ました。

上記ソースにありますように、モック化するクラスをフィールド変数に定義し、「@Mocked」というアサーションを付けるのがお約束です。
そして、具体的にどんな機能に差し替えるのかを書いているのが、「NonStrictExpectations」の内部の部分です。

意味は以後の連載でご説明するとして、今回の所は動きを確認出来ればOKでしょう。

カバレッジ


私の環境だと、Eclipseのコンソールには以下のように表示されます。


どうやらカバレッジも出力してくれたようですね。
導入段階で「jmockit-coverage.jar」を入れましたので、自動的にカバレッジまで出力してくれたようです。

さっそく見てみましょう。

まず、index.htmlを開くと、以下が表示されます。


どうやら全体のカバレッジ率を出してくれる画面のようです。
今回の場合「0%」になっていますが、これは本体ソースをモックで潰して実行してしまった為、本体ソースは全く実行していないからです。
このように、jmockitはちゃんと「本体ソースを通った箇所」「モックで潰した箇所」を別々にカウントしてくれますので、カバー漏れ等は発生しません。

クラス名をクリックすると、カバレッジ詳細が表示されます。


画像は赤一色になっていますが、通過した箇所としていない箇所をちゃんと別々の色で表示してくれますので、分かりやすいです。

これにてカバレッジの出力も確認出来ました。

注意点


ここで一つ注意を入れておきたいと思います。
jmockitの公式サイトを見ると、以下のような文章が。

HTML reports: a multi-page HTML report is written in the "coverage-report" directory, under the current working directory (a different output directory can be specified if needed). The directory is created if it doesn't yet exist; its contents are overwritten if previously generated. The report will include pages containing all Java source files covered by the test suite. By default, the tool looks for ".java" source files inside all directories of name "src" found directly or indirectly under the current working directory; any intermediate sub-directories between "src" and the top-level package directory, such as "src/java" for example, are also searched.

何と、カバレッジを出力する際は「フォルダ名」の指定があるようで、デフォルトでは「src」の配下がソース本体として扱うだそうです。

つまり、ソースフォルダの構成が影響します。

src
 L main
    Ljava
    Lresource 
 L test
    Ljava
    Lresource

みたいにsrc配下に「main」と「test」を置いてしまうと、testソースまでカバレッジ対象になってしまい、HTML出力にゴミが混ざってしまいます。

また別のパターンとして、

main
  Ljava
  Lresource 
test
  Ljava
  Lresource

みたいにsrcという名前のフォルダが無いと、カバレッジが出力されません。

では私はどうしたかと言うと、

src
  Ljava
  Lresource
test
  Ljava
  Lresource

こういう構成にしてみました。
これなら綺麗に出力出来るようです。

「カバレッジが出ないぞ!?」と困っている人は大概はコレだと思いますので、ご確認下さい。


終わりに


ひとまずこれでJMockitのインストールが出来ました。

次回からはJMockitの各種詳細機能の検証に進みます。

高機能なライブラリですので長くなると思いますが、最後までお付き合い下さい。

0 件のコメント:

コメントを投稿