Javaのモックアップフレームワーク「mockito」でリクエスト／セッションを再現する

オイシックスの事例から学ぶ、JavaのWebアプリに自動テストを導入する方法　第3回

　本題に入る前に、弊社でのJUnit導入時のエピソードをご紹介させていただきます。オイシックスでは昨年から開発推進セクションというチームが作られました。このチームは、開発スピードと品質アップをKPIとしているチームです。年度の最初に取り掛かった仕事がJUnitの導入だったと思います。今ではJUnitのテストケースを書くことを拒否する人はいなくなりましたが、導入当初は開発スピードを重視する開発チームから「JUnitでユニットテストをしないで、従来通りのテストで良いかな？」と言われることも多くありました。テストケースのコーディングは、プロダクトコードのコーティング時間より長く掛かります。リリースは早ければ早いほど、ビジネスとしてのチャンスは多くなりますし、事業部から早いリリースを期待されるチームにとっては当然なことだったと思います。

　しかし、開発推進セクションとしてリーダーを中心に「基本的には必須ですが、相談には乗ります」と伝えてきました。もちろん、こちらとしても妥協することはありますが、基本は書いてもらうように言い続けたことは良かったと思います。今ではテストケースは2,000ケース以上となり、毎日jenkinsからもallTestの結果が送られてくるようになったのですから。そんなやりとりをしていく中で、こんなFAQも生まれました。

• Q：巨大なメソッドで1行だけ修正したのですが、そのメソッド内をすべてテストしないといけないの？
• A：基本はテストしてください。

　ただしトラブル対応など、どうしてもすぐにリリースしないといけない場合はその限りではありません。

　結果的にこのようなFAQは、開発メンバーにJUnitの導入を受け入れてもらうために必要なことだったと思います。やはり、開発スピードを重視するチームにとって、やることが多くなることは受け入れにくいことではありますのでJUnit導入のための一つの潤滑油になったのではないでしょうか。

　それでは、連載第3回目の本題に入ります。本稿では、リクエストとセッションをmockitoを使って再現する方法をコード交えてを説明していきます。それでは、よろしくお願いいたします。

対象読者

　今回の対象読者は、下記のとおりです。

• 実際の開発プロジェクトへの自動テスト導入を検討されている方
• JavaによるWebアプリケーション開発についての知識がある方
• JUnitの基本的な知識がある方

必要な環境

• JDK 7
• Eclipse 4.3
• Tomcat 7

mockitoとは

画像はhttps://code.google.com/p/mockito/より引用

　mockitoは、Javaのモックフレームワークです。主にオブジェクトのモックを作るときなどに使用します。読み方はモキート？ではないかと私は思います。名前の由来はカクテルのモヒートからきているようです。mockitoのページに名付けの理由が書いてありましたので、以下に掲載します（私の意訳が含まれます）。

　「mockitoは本当においしいモックフレームワークです。クリーン＆シンプルなAPIで美しいテストを記述できます。作成したテストは読みやすく、きれいな検証エラーを生成するので、mockitoはあなたを二日酔いにしません」

　使いやすいAPIのため理解しやすく、美しくテストを記述できる。そして可読性も良くなる。また、検証エラーも読みやすく理解しやすいことなどが、多くの方に好かれている理由なのではないでしょうか。これが名前の由来なのではないかと私は思いました。

　モヒートを飲んだことがある人ならイメージできるのではないでしょうか。シンプルでミントが入っていて、さらっとスッキリした味で飲みやすい（飲み込みやすいAPI）。そして二日酔いしない（検証エラーが読みやすく、コードも読みやすいので後日負債になりにくい）。分かる気がします。

　ちょっと脱線ぎみになってきましたので、mockitoがどんな場面で役に立つかを説明していきます。

　例えば、DBの状態によって複数のステータスを返すようなメソッドがあったとします。そういったメソッドをテストするときは、そのステータスの状態をデータベースに作る必要があると思います。多くのレコードを作らなければいけない時もあるので、時間も手間も掛かりますよね。そういったときはmockitoを使うことによって、データベースに状態を作らなくても、テストできるようになります。次に具体的な例を書いて説明します。