 |
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
| JUnitのメリット | ||||||||||||||||||||||||||||
|
ここでは、単に動作を確認するためのものとしてJUnitを紹介しましたが、JUnitのメリットとデメリットについて、もう少し考えてみましょう。まず、JUnitのメリットとしては次のことが考えられます。 |
||||||||||||||||||||||||||||
| デグレートを防ぐ | ||||||||||||||||||||||||||||
|
作ったときには正常なプログラムも、仕様変更やバグの修正などで、他のロジックに潜在的なバグを生むことがあります。JUnitのテストを記述しておけば、このようなデグレートを防ぐことができます。 |
||||||||||||||||||||||||||||
| リファクタリングしようという気になる | ||||||||||||||||||||||||||||
|
「動いているものは触るな」というのがソフトウェア業界の定説で、間違っていませんが、その場しのぎのコードの拡張を繰り返していくと、そのうちどこかで破綻します。これを防ぐために、度々リファクタリングを行い、コードをキレイに保っておくことが重要ですが、それでもデグレートが怖いです。単体テストを書いておくことで、リファクタリングを持つ勇気が湧いてきます。 |
||||||||||||||||||||||||||||
| テストが好きになる | ||||||||||||||||||||||||||||
|
基本的にプログラマはテストが嫌いです（と思います）。それは、余計な作業が増え、自分の開発生産性が下がるというイメージがあるからです。しかし、「テストを書いた方がトータルで開発効率は上がる」ということを頭で理解できれば、プログラマも進んでテストを書くでしょう。 |
||||||||||||||||||||||||||||
| 仕様が早い段階で明確になる | ||||||||||||||||||||||||||||
|
あいまいな仕様のまま、とりあえず作ってみたというコードは、あとになって違うとわかり、直すハメに陥ります。テストを書くと、仕様のあいまいな部分が早い段階で解消されます。 |
||||||||||||||||||||||||||||
| 利用法がわかる | ||||||||||||||||||||||||||||
|
テストコードは、単に動作を保証するため、だけでなく、コードのサンプルとしても重宝します。テストコードを見ると、そのクラスがどのような使われ方をするのか一目瞭然です。引継ぎをした場合でも、わかりにくい日本語を読むよりテストコードを見た方が理解しやすい場合もあります。 |
||||||||||||||||||||||||||||
| JUnitのデメリット | ||||||||||||||||||||||||||||
|
一方、JUnitを利用する上でのデメリットや限界には次のものが考えられます。 |
||||||||||||||||||||||||||||
| 余計な作業が増える | ||||||||||||||||||||||||||||
|
テストケースをどこまで書くかというのはよく議論になります。すべてのメソッドのすべての条件に対してテストを書くのは、よほどスケジュールと人員に余裕のあるプロジェクトでないとできないでしょう。この場合は、重要な部分、不安な部分に対して重点的にテストを書いておくとよいでしょう。 逆に、まったくテストケースを書かず、mainメソッドを書いて動作確認をしているのであれば、代わりにテストケースを書いておいた方が、書いたテストケースを有効に使えます。 |
||||||||||||||||||||||||||||
| テスト嫌いになる | ||||||||||||||||||||||||||||
|
カバレージ率やステップ数に対するテストケース数などを決めているケースをよく見かけます。これらの数値は、外注管理やマネージャにとっては、品質管理のための指標としてわかりやすい指標です。一方、実際に作業しているプログラマが「意味ない」と思ってやっていると、あまり効果が上がらないどころか生産性にマイナスの影響を与えます。 現場レベルでこのようなモラールの低下があると、品質確保のためのテストでなく、テスト数のための適当なコードが増えるだけになります。たとえこのような指標を使う場合でも、お互いが納得できる程度の数値を設定し、また「テストは意義がある」ということを現場レベルで徹底しておくことが重要でしょう。 |
||||||||||||||||||||||||||||
| 仕様変更時の手間 | ||||||||||||||||||||||||||||
|
単体テストはリファクタリングを促進しますが、仕様変更時には修正対象が増えます。テスト対象のコードを変更するのに加え、テストケースも修正していく必要があります。せっぱつまったときには、テストケースの修正が置き去りにされ、通らないテストがコメントアウトされていくこともあります。 "とりあえず速攻で開発して、リリース後に細かいところは直していく"というスタイルをとるのであれば、テストはせいぜい共通部品や、一部複雑な処理ぐらいに書いておくぐらいが適切かもしれません。これは、単体テスト自体の意義の話でなく、仕様調整、スケジューリング、開発プロセスの話かもしれません。 |
||||||||||||||||||||||||||||
| できない種類のテスト、向かないテストがある | ||||||||||||||||||||||||||||
|
サーブレットやフレームワークを利用したテストは、JUnitだけではできません（この場合、CactusやHttpUnitなど他のツールを利用することができます）。データベースがらみのテストも、テスト結果の確認にイチイチSQL文を記述していては、手間の方が多くなります（この場合はDbUnitなどの利用が検討できます）。JUnitでGUIのテストやマルチスレッドがらみのテストを記述するのも難しいです。 また、JUnitは単体テスト用のツールなので、性能テスト、使い勝手のテスト、結合テストなどは、必要に応じて別途行います。 JUnitでカバーできる範囲を考えて、他の部分については他の手段を検討しておく必要があります。 |
||||||||||||||||||||||||||||
| まとめ | ||||||||||||||||||||||||||||
|
今回はJUnitの利用法について説明しました。ソフトウェアの品質を考える上で、JUnitは手軽に簡単に効果の出せるツールでしょう。Eclipseは、JUnitの作者も開発に参加しているためJUnitが非常によく統合されており、Eclipseを使った単体テストは非常にスムーズに行えます。 |
||||||||||||||||||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
-
-
連載
