SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

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

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

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

 しかし、開発推進セクションとしてリーダーを中心に「基本的には必須ですが、相談には乗ります」と伝えてきました。もちろん、こちらとしても妥協することはありますが、基本は書いてもらうように言い続けたことは良かったと思います。今ではテストケースは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/より引用
画像はhttps://code.google.com/p/mockito/より引用

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

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

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

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

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

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

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
Cartクラスでのモック使用例

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
オイシックスの事例から学ぶ、JavaのWebアプリに自動テストを導入する方法連載記事一覧

もっと読む

この記事の著者

山田 昌平(オイシックス株式会社)(ヤマダ ショウヘイ)

オイシックスでは 運用→開発→開発推進を担当してきました。あと、ITイベントの協賛も担当しております。イベントは、技術的な面、エンジニアとしての考え方など、本当に学ぶことが多いのでおすすめです。お会いすることもあると思いますので気軽に声をお掛けください。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/7719 2014/04/14 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング