#テストの必要性
以前のシステム開発と言えば、ウォーターフォールのような要件から設計、実装、テストのような徐々に作業を細分化し最後にテストを行う手法が主流、というかSierとかでは基本今でもこの手法が多いはず。
しかし、現在はアジャイル開発の普及にともない、TDD、BDDに代表されるようなテスト重視の開発スタイルが増加している。
その中で実際テストコードを書いてみようとすると、Javaではテストフレームワークやツール、ライブラリ等が多数あり、どれを選択すべきか悩みどころになってくる。
ここではそれらを整理するため、Javaのテストコードを書くときに必要な情報をまとめておきます。
#どれを使うか・・・
個人的には、どれを使いうかと考えた時に以下に注意している。
-
簡単、シンプル
テストコードをするために、時間がかかり過ぎたり、可読性が低下したり、ロジックがあまり複雑になるようなものは避ける。 -
情報量
実際コードを書くと、疑問や問題にぶつかったりするので、その際はある程度情報量が多いものを選ぶことが多い。
テストを重視して素晴らしいテストコードは出来ても、実際のコードはまともに動かない。
では話にならない。情報量の多い=問題が起きた時の作業時間短縮。なので、そのあたりのバランスは重要だと思う。 -
再利用性
独自の技術や、記述すぎて開発がストップしたときに、他の技術に以降できない。また、一から調べ直さないと使えないってものは極力避けたい。
エンジニアとしてはそれはそれで勉強になるけど。。。
#Javaのテストフレームワーク、ツール、ライブラリなど
Wikipedia ユニットテスト・フレームワーク一覧#Java
Web Site Test Tools and Site Management Tools - Java
ざっとみただけでも多数あり、中には既に開発がストップしているものもある。
#人気のあるのは
実際に使われるることの多いものものをまとめ。
####ユニットテストフレームワーク
- JUnit
Javaのテストと言えばまずこれ。機能も必要十分で情報も充実してる。主に単体テストフェーズの自動化を行う。
- TestNG
JUnitより後発のため、記述の簡潔化、機能追加などある。使い方はJUnitとほぼ同等で、JUnitからも簡単に移行できる。
現状両者開発も続いているのでTestNGの方が後発のため、記述が簡単だったり、機能的に充実している部分もあるが、JUnitもアップデートで機能充実が図られている。
その気になれば大半のテストはどちらでも書けるので、どちらが圧倒的に優位ってことはない。
現状JUnitを使っている現場の方が圧倒的に多い気がする。
参考
技術/TDD/JUni 4.10 と TestNG 6.x系 機能比較(by JUnit実践入門)
####モックライブラリ
- Mockito
- JMockit
そのほかにも、jMock、EasyMock、PowerMockなどMockライブラリは多数ある。
その中で機能の多さではJMockitが多機能。記述的にはMockitoの方が簡単に記述しやすい。
参考
MockingToolkitComparisonMatrix
JMockitは理想的なモックフレームワーク
####データベース
- DBUnit
Junitの拡張で、テストデータをDBに投入、後片付け、メソッド実行後のDBの状態を確認などを行う機能がある。
####ブラウザ
- Selenium
ブラウザテストの自動化を行う。
テスト対象は画面ベースのため、プログラミング言語に関係なくテストを行える。
#結論
今自分が使うなら、JUnit + Jmockit + DBUnit + Selenium。
後は、使うアプリケーションフレームワークがもとから上記の機能を有しているテスト機能。
アプリケーションフレームワーク独自の機能をより完結にテストできる場合が多いので、あればそちらを優先したほうが良い場合もある。
#おまけ
便利なツール集
#####Jenkins
継続的インテグレーションツール。
要は予め準備していた、テスト、ビルド、デプロイなどの処理を自動化、バッチ実行するために使用する。
#####Jmeter
パフォーマンステスト用のツール。
個人では使うことは少ないと思うが、仕事などでシステムに同時に多数のアクセスを行った場合の性能テストを行うときに使ったりする。
システム全体のテストというより、負荷の掛かりそうな機能に対して部分的に使用する。
#####djUnit
主にカバレッジ測定のために使用するEclipseプラグイン。
条件分岐などの網羅が正確に行われているかなどの確認が簡単に行える。
#####Checkstyle
コーディング規約をチェックするための静的解析ツール。
例えばソースコードにおける中括弧や、空白スペースの記述位置などコーディングスタイルに関する指摘のほか、クラス名、定数、変数、メソッド名などの命名規則がコーディング規約（あるいは命名規約）として定義された規則に従い、正しく記述されているかどうかをチェックする。
FindBugsと比べると、特にコーディングスタイルや命名規約のチェックが優れている。
#####FindBugs
潜在的なバグをチェックすることができる静的解析ツール。
例えばメソッドのパラメーターを、nullチェックを行わずに使用しているため、NullPointerExceptionが発生する可能性などを指摘。
Checkstyleと比べると、より潜在的なバグの検出が得意なツール。
#####Quick JUnit
テストコードを書くときに便利なショートカットなどがあるEclipseプラグイン。
Ctrl + 9 ： ソースコード↔テストコード
Ctrl + 0 ： 選択しているメソッドの実行
Ctrl + Shift + 0 ： 選択しているメソッドのデバッグ実行
関連書籍
このあたりは、見といたほうがいいかも。
現場で使えるソフトウェアテスト Java編 → まとめ
経験ゼロでもできるプログラミング現場の単体テスト
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)
##最後に
ここに書かれていることは所感でまとめたため、ご意見ご要望、誤りがありましたら訂正しますので、編集リクエスト、コメントをもらえればと思います。