しかし、開発推進セクションとしてリーダーを中心に「基本的には必須ですが、相談には乗ります」と伝えてきました。もちろん、こちらとしても妥協することはありますが、基本は書いてもらうように言い続けたことは良かったと思います。今ではテストケースは2,000ケース以上となり、毎日jenkinsからもallTestの結果が送られてくるようになったのですから。そんなやりとりをしていく中で、こんなFAQも生まれました。
- Q：巨大なメソッドで1行だけ修正したのですが、そのメソッド内をすべてテストしないといけないの？
- A：基本はテストしてください。
ただしトラブル対応など、どうしてもすぐにリリースしないといけない場合はその限りではありません。
結果的にこのようなFAQは、開発メンバーにJUnitの導入を受け入れてもらうために必要なことだったと思います。やはり、開発スピードを重視するチームにとって、やることが多くなることは受け入れにくいことではありますのでJUnit導入のための一つの潤滑油になったのではないでしょうか。
それでは、連載第3回目の本題に入ります。本稿では、リクエストとセッションをmockitoを使って再現する方法をコード交えてを説明していきます。それでは、よろしくお願いいたします。
対象読者
今回の対象読者は、下記のとおりです。
- 実際の開発プロジェクトへの自動テスト導入を検討されている方
- JavaによるWebアプリケーション開発についての知識がある方
- JUnitの基本的な知識がある方
必要な環境
- JDK 7
- Eclipse 4.3
- Tomcat 7
mockitoとは
mockitoは、Javaのモックフレームワークです。主にオブジェクトのモックを作るときなどに使用します。読み方はモキート？ではないかと私は思います。名前の由来はカクテルのモヒートからきているようです。mockitoのページに名付けの理由が書いてありましたので、以下に掲載します（私の意訳が含まれます）。
「mockitoは本当においしいモックフレームワークです。クリーン＆シンプルなAPIで美しいテストを記述できます。作成したテストは読みやすく、きれいな検証エラーを生成するので、mockitoはあなたを二日酔いにしません」
使いやすいAPIのため理解しやすく、美しくテストを記述できる。そして可読性も良くなる。また、検証エラーも読みやすく理解しやすいことなどが、多くの方に好かれている理由なのではないでしょうか。これが名前の由来なのではないかと私は思いました。
モヒートを飲んだことがある人ならイメージできるのではないでしょうか。シンプルでミントが入っていて、さらっとスッキリした味で飲みやすい（飲み込みやすいAPI）。そして二日酔いしない（検証エラーが読みやすく、コードも読みやすいので後日負債になりにくい）。分かる気がします。
ちょっと脱線ぎみになってきましたので、mockitoがどんな場面で役に立つかを説明していきます。
例えば、DBの状態によって複数のステータスを返すようなメソッドがあったとします。そういったメソッドをテストするときは、そのステータスの状態をデータベースに作る必要があると思います。多くのレコードを作らなければいけない時もあるので、時間も手間も掛かりますよね。そういったときはmockitoを使うことによって、データベースに状態を作らなくても、テストできるようになります。次に具体的な例を書いて説明します。
