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テストでテストできるようにしていきましょう。