1. はじめに

今回はTERASOLUNA5.x（=SpringMVC+MyBatis）アプリにおけるJUnitテストの概要について、自社の研修にて説明している内容を紹介したいと思います。
TEASOLUNA5.xの各コンポーネントを対象にテストを行います。各コンポーネントの説明については「５分で分かるTERASOLUNA5.x ！」を参照ください。

（前提と方針および注意事項）

今回説明するテスト方法は、コンポーネントを結合しているが、全て「単体テスト」と呼ぶこととする。必要であれば各自のPJの定義に従って読み替えること。
可能な限り、実際に動作させる環境に合わせることとする。
ソースコードだけでなく、設定（コンフィグレーション）も検証対象とする。
可能な限りモックは利用せず、末端のコンポーネントからテストしつつ結合する積み上げ方式とする。

（再掲）各コンポーネントとデータと処理の流れ

各コンポーネントと単体テストの対象範囲

2. 単体テスト①（オプション）

RepositoryインターフェースとMapperファイルの動作確認を行うための単体テスト
実際にMapperファイルを読み込んでDBアクセスを行うため、Mapperファイルの内容についても検証可能
MapperファイルやSQLの内容が複雑な場合に実施する

3. 単体テスト②（必須）

Serviceを実行し、関連するドメイン層のコンポーネントを実際に動かして動作確認を行う単体テスト
業務ロジックはドメイン層に記述するため、業務ロジックのテストという意味で単体テスト②は必ず実施すべきである
トランザクション境界はServiceのメソッドのため、トランザクションについても確認可能である

4. 単体テスト③（条件に応じて）

FormとValidationの動作確認を行うための単体テスト
独自のValidationを実装した場合に実施する
Formの入力チェック仕様を、JUnitのテストとして効率的に確認したい場合にも利用する

5. 単体テスト④（オプション）

mockmvcを利用し、アプリケーションサーバにデプロイすることなく、SpringMVCのアプリケーションの動作を再現して行う単体テスト
アプリケーション層およびドメイン層のコンポーネントを実際に動かして動作確認を行うため、デプロイした状態とほぼ同様の環境を実現することができる
Tiles、JSPを利用したビューについてはレンダリングが行われないため、mockmvcのテストでも対象外となる
JSONでデータをやり取りするいわゆるRESTful Web Serviceの場合、mockmvcでレスポンスのJSONも検証することができる

6. さいごに

今回はTERASOLUNA5.x（=SpringMVC+MyBatis）アプリにおけるJUnitテストの概要について説明しました。
実際のJUnitテストの実装方法についてはこれから記事にしていく予定ですが、ここでは、ほとんどのコンポーネントをJUnitのテストとして実装できることを覚えてもらえれば十分です。
JUnitのテストであればいつでもコマンド一つで簡単に実行できるため、できるだけJUnitテストでテストできるようにしていきましょう。