2013年10月30日水曜日

最強モックツール JMockit その11 Eclipseプラグイン

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

長く続いた「JMockit」の記事も本日が最終回です。
JMockitは非常に多機能なライブラリなので他にもまだまだ機能はあるのですが、大抵の開発ならば前回までの内容で対応出来ると思います。
何回か使ってみて、『もっとこういう機能が無いかな?』という状況になった時、改めて探してみるのが良いかと思います。

さて、最後はチラッと小ネタをご紹介します。

Eclipseプラグイン


JMockitには、Eclipse上での入力を支援してくれるプラグインがあるようです。


導入すると、「ctr + スペース」で以下のように入力候補が出てくるようになります。


他にも、「書き間違えている場合に赤くエラーを出す機能」「テスト対象になっているメインソースのジャンプする機能」などがついています。

別に導入必須という程の大した機能ではありませんが、こうした「ちょっと便利な機能」も忘れず押さえておくことで、日頃の開発効率を高めていくようにしたいものですね。

これからのJMockit~JMockit2~


何と、Googleの開発サイトでは「JMockit2」の開発が始まっているらしいです。


まだ開発途中ですが、『JMockit1とは違う視点から、もっとシンプルで優れたモックライブラリを作る!!』との触れ込みです。

現時点で十分に優れたライブラリかと思いますが、確かに調べていて少し難しいと感じることもあり、「シンプルさ」にはまだ改善の余地があるのかもしれません。

完成がいつになるかは分かりませんが、Java単体開発者としては耳寄りな状況として要チェックです。

首を長くして完成を待ちたいと思います。

終わりに


これにてJMockitの連載は終了です。

連載を終えるに辺り、JMockitに関する所感を述べるならば、上にもありますが「結構難しい!!」ですね。
そもそも、モックという発想自体が黒魔術ですので、何年もJava開発を行って基本を押さえている技術者ならば兎も角、経験の浅い人が触ったら混乱することになると思います。

また、『チームの全員がJMockitに精通している』という超精鋭チームを用意することも至難でしょう。

というわけで、「せっかく覚えたJMockitだ。ぜひ使いたい!!」という流行る気持ちは押さえて、

  • モックを使わなくてもテスト出来るクラス設計にする。
  • どうしても必要な例外部分だけ、JMockitを使用する。

といった程度の水準で導入するのが一番現実的ではないでしょうか。

例えば「正常系は普通にテストする。異常系はJMockitを使う」など、開発指針のレベルで適切な運用方法を考える所からがJMockitの始まりかと思います。


以上でJMockitの連載を終わります。
ご愛読ありがとうございました。

2013年10月21日月曜日

最強モックツール JMockit その10 コンストラクタ差し替え

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

現在はモックツール「JMockit」の使い方をご紹介しています。

今回はコンストラクタの差し替えです。

コンストラクタの差し替え

前回は「メソッドを丸ごと差し替え」を行いましたが、
今回はその延長線で「コンストラクタ」の差し替えです。

コンストラクタは普通のメソッドとは違うということか、他のモックツールを見てもコンストラクタには非対応ということが多いようです。
しかしコンストラクタのモック化を必要とするシチュエーションも少なからずあるもの。
例えば、バッチの開発。偶に見るのですが、コンストラクタで環境設定ファイルを読み込む作りになっていることがあるのです。
しかも、前もって用意されている正規の環境設定ファイルは本番実行用で、テストの時はテスト用ファイルを読み込まなければならない、という場合も結構あります。

しすれmそういう現場では必ず以下のような会話で盛り上がります。


「あれ? テストが動かないぞ?? どうなってんの???」⇒「設定ファイルの差し替えを忘れてるんですよ」


これを何回でも繰り返すのが人間というものです。どの現場に行っても100%コレでした。
というわけで、ファイルの差し替えとか設定値の切り替えとか、そういう作業はJMockitを使ってテストソースの中に埋め込んでおく方が楽です。
ぜひ使ってみてください。

では、JMockitにおけるコンストラクタ差し替えの記述方法をご紹介しましょう。
まず、サンプルとして以下のようなコンストラクタを含んだクラスを作成します。

public class ConstructorSample {

 public ConstructorSample() {
  System.out.println("★コンストラクタ処理★");
 }

}

サンプルですのでprintlnのみの処理ですが、本番ではここで色々処理しているという想定です。
これに対し、テストソースの方は以下のように書きます。

public class ConstructorSampleTest {

 @Test
 public void test() {
  new MockUp<ConstructorSample>() {

        @Mock void $init() {
         System.out.println("★コンストラクタ差し替え★");
        }
  };

  new ConstructorSample();
 }

}

コンストラクタの場合はメソッド名の指定が普通には指定できませんので、『$init』という特殊記号を使うわけです。

書き方の要領は前回と全く同じですので、『$init』を使うのだということを知っていれば簡単に使うことが出来るでしょう。


終わりに


JMockitは高機能なライブラリなので連載が長引きましたが、
今日までの記事で殆どのケースに対応可能だと思います。

次回は最終回、JMockit開発を支援するEclipseプラグインをご紹介します。

2013年10月15日火曜日

最強モックツール JMockit その9 メソッド丸替え

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

現在はモックツール「JMockit」の使い方をご紹介しています。

今回はメソッドの中身の丸ごと差し替えです。

メソッド全体の差し替え

今までご紹介してきたモック機能というのは、『元々のメソッドを実行しないで、仮の値を返す』というものです。

例えば、ログインチェック機能の場合、
本来の機能であれば『ログインIDとパスワードをチェックして、正しい場合はtrue、間違っている場合はfalseを返す』だったとします。
しかし、モック化することによって『いつも固定でtrueにする』とか、そういう感じです。

この場合、元々のメソッドは実行していませんので、DBにアクセスに行っていません。
ただ単に『true』という値が帰ってくるだけです。

このように、『返り値だけあればいい』という状況であれば今までのやり方でOKです。
しかし、そうではなくて、『別の処理をちゃんと実行して欲しい』という場合は、これではダメです。

例えば、以下のような状況です。

  • DBに間違った値が入った時のテストだから、本来の機能はモック化して潰し、代わりに間違った値をインサートさせたい。
  • メール送信機能のテストなんだけど、メール送信処理自体は実際にはメールを送信しなくていいからモック化する。でも、同時に行っている一時ファイル削除処理は行っておく必要がある。

このように、『ダミーの値を返すだけではなくて、違う処理をやりたい』という場合です。
こういう場合は、元々のメソッドをぶっ潰して、違う機能を書いてしまいましょう。

『メール送信後、ファイルを削除する』機能をモック化するというシチュエーションを想定します。
(サンプルなので、printでその処理を行ったという想定とします)

public class MailManager {
 public void sendMail(){
  System.out.println("★メールを送信する。★");
  System.out.println("送信した添付ファイルを削除する。");
 }
}

JUnitは単体テストですが、メール送信はプログラムだけでなくメールサーバも必要とします。
こういう風に違うサーバを必要とする処理のテストは結合テストで行って、単体テストフェーズではモックで済ます、というのは常套手段と言えるでしょう。

しかし、同時に行っている添付ファイル削除処理は実施しなければ都合が悪いということもあるでしょう。
もしくは、『メール送信は成功したけど、ファイル削除は失敗した』という状況を作りたかったりするなど、細かい要望は色々あります。

そういう場合、モックでメソッドを新規作成してしまえば良いのです。

以下がそのやり方です。

@Test
 public void testCreateFile() {
  new MockUp<MailManager>() {
   @Mock
   void sendMail() {
    System.out.println("ファイル削除(差し替え)");
   }
  };
  //メール送信
  MailManager manager = new MailManager();
  manager.sendMail();
 }

JMockitの場合、今回新規登場の『MockUp』というクラスを使うことで実現できます。

使い方も分かりやすいかと。
MockUpクラスの中で同じ名前のメソッドを書いて、@Mockをつければ、それだけで後は自動でモック化されます。

直感的に分かるようによく出来ているライブラリだと感心してしまいます。

終わりに


今回ご紹介したサンプルは、実際のところは回避可能でもあるんですよね。
だって、『メール送信』と『ファイル削除』を別々のメソッドにして、メール送信メソッドだけモック化すれば良いのですから。
しかし、実際の開発だとクラス設計がJUnitのことまで考えられていなくて、こういう作りになっていることもしばしば。
不本意ながらに結構お世話になってしまう機能かもしれません。

もしくは、『ファイル削除失敗』みたいに現実には実現出来ないシチュエーションを作るにも便利です。

代替機能を自分で作る手間はありますが、こんな風に自由に作り込める機能は大変助かりますね。

引き続きJMockitのご紹介をしていきます。