第4回この記事は「こちら」に移動しました。Mobster/メディアファイブ株式会社2003/3/7今回から2回にわたり、システムのシートベルトとでもいうべき「テスト」について考えていきます。XPではテストに関して「テストファースト」に代表される、独自のアプローチを取っています。それらは通常の開発に慣れた人にとっては、奇異に映るかもしれません。実際に開発に取り入れて実践してみると、大変合理的な手法であることに気付くと思います。今回は「テストの意義」と「テスティングフレームワーク(主にJUnit)」について解説し、その後Eclipseを利用した効果的な単体テストの活用法に焦点を移します。本連載の今後の講習カリキュラムはこういうイメージになる■テストのプラクティスの位置付けXPはテスト駆動型の開発プロセスです。テストはXPの各プラクティスの中で最も中心的な役割を果たします。テストのプラクティスを実践することで「リファクタリング」「シンプルな設計」「継続した結合」「短期リリース」「週40時間」などのほかのプラクティスが強化されます。テストはプログラマが最初に取り入れやすいプラクティスの1つです。XPを検討する前段階のステップとして、ユニットテストを部分的に導入してみるのもよいと思います。ユニットテストなども未体験の方は、テストを自分の開発スタイルに取り込み、XPへの扉を開きましょう!■XPにおけるテストの意義XPではすべてのコードに対してテストが存在します。これによって、短期間でバグが少なく、高品質のシステムを構築することができます。このことは絵空事のように聞こえるかもしれませんが、いつでも実行可能なテストを各クラスに用意することでバグの発生は限りなくゼロに近づきます。リファクタリングや仕様変更などの前に、システムのすべてのテストを実行して、改造後にもう一度テストを行えば、改造が正しく行われたことを保証することができます。自動化されたテストXPでのテストとは自動化されたテストのことを指します。「自動化されていないテストはテストにあらず」というわけです。自動化されたテストならば、テストを「いつでも」「素早く」「すべて」実行することができます。一般的によく行われる「System.out」による目視やステップ実行によるテストは自動化されていないので、システムのテストとしては不十分だといわざるを得ません。普通はJUnitなどのテスティングフレームワークを利用して自動化されたテストを構築します。筆者は学生時代からテストと名の付くものすべてが苦手でした。プログラマに成り立てのころもテストは面倒くさく、後回しになりがちでした。それがXPやテストファーストを実践してからは、テストが大好きになりました。テストなしのプログラムは考えられません。ユニットテストなしで今までうまくいっていたのは奇跡だと思えるくらいです。テストを行うことでプログラマは「自信」を持つことができます。それは「自分が書いたコードは正しく動いている」ということへの「自信」です。「テストを通す」という短期的な目標が明確になり、開発自体にリズムが出てきます。プログラマはテストによって救われます。■ユニットテストと受け入れテストXPには2つのテストがあります。ユニットテスト:ユニットテストはプログラマが書き、プログラマが実行します。ユニットテストとはクラス(モジュール)の単体テストのことです。クラスの「振る舞い」が期待どおりに動くことを中心にテストを作成します。本連載ではこのユニットテストを中心に解説します。受け入れテスト:受け入れテストは顧客が書き、顧客が実行します。受け入れテストを行うことで顧客はシステムの振る舞いを確認することができます。自動化された受け入れテストがあれば、システム全体としての「完成度」についていつでも知ることができます。■テストファーストプログラミングXPではテストファーストでプログラムを作成します。テストファーストとは実装コードのコーディングに入る前に、その実装コードに対するテストコードを先に書くことです。これには次のようなメリットがあります。仕様の明確化:コードを書く前にテストが作れないということは、そのコードの振る舞いがはっきり理解されていないということになります。逆の言い方をすると、テストファーストならば、コードを書くときには振る舞いがはっきりしているので、コードを書くことに専念できます。テストコードを書くことが、クラスやメソッドに対する詳細設計になります。すべてのコードに対してテストが作成できる:テストファーストならば、すべてのコードに対するテストが必ず存在することになります。「コードが動いたからテストは書かなくていいや」という考えを防ぐためにもテストファーストは有効です。ドキュメントとしての役割:テストは最高のドキュメントです。テストは、クラスの包括的な振る舞いを確認していますので、テストを見ることでクラスの使用法、仕様が理解できます。シンプルな設計:テストを先に書くことで、シンプルな設計/実装を行うようになります。ゴールの明確化:テストを先に書くことで、コーディングのゴールを知ることができます。ゴールとはテストに通ることです。これはプログラマにとって精神衛生上良い効果をもたらします。筆者はXPではないプロジェクトでテストファーストを試みたことがあります。開発期間の制限、ユニットテストが納品物として認められないなどの理由で、すべてのコードをテストファーストで書くのは難しいものがありました。その結果テストがまったくないクラスがいくつもできてしまいました。その時点では「まぁ動いているからいいか」と思っていました。結合テストやデバッグ、メンテナンス時に、テストを作らなかったことを大変後悔することになりました。正しい動作を保証してくれるユニットテストがない場合、変数名を1つ変えることにすらおびえてしまいます。テストを作る余裕すらないコードは、その余裕のなさが反映され、各所にバグが入り込み、そのバグ退治のためのバイパスコードが複雑に入り込んでいました。「動いているものには触るな」という最悪の事態に陥ってしまいました......この経験から次のことを学びました。「テストがない」クラスはカルテのない末期症状の状態もしテストファーストが守れなくても、各クラスに対するテストは実装後でもよいのできちんと揃えておくべきです。■テスティングフレームワークを活用しようテストにはテスティングフレームワークを活用しましょう。JavaにはXPの生みの親であるケント・ベック氏が開発したJUnitがあります。JUnitには次のメリットがあります。テストが簡単に実装できる:テストは簡単に、なるべくプログラマにかかる負担が少ない形で実装するのが望ましいでしょう。JUnitではテスト用の基底クラスを継承してテストクラスを作成しますので、最小限のコーディングでユニットテストを構築できます。テストが統一的に作成できる:JUnitを用いない場合、単体テストは各プログラマがそれぞれのやり方で実装してしまいます。フレームワークという枠組みがあることで、統一的かつ一貫した方法でテストを行うことができます。テストと実装コードの分離:JUnitでは実装クラス「Hoge」に対して、テストクラス「HogeTest」を作成します。このことにより、テストコードで実装コードを分離することができます。Antなどほかのツールとの連携:JUnitはほかのツールから利用されることも考慮して設計されており、AntやIDEとの連携がスムーズにできます。テスティングフレームワーク「JUnit」のインターフェイスコラム:テストの使用を広げていこう!テストはXP開発の中でなくても有意義なものです。テストを活用されている方なら誰もがそう思うでしょう。テストの使用を周りの開発者に勧めるのは困難な場合が多いのです。それは、成果物にならない点と、一見無駄に見えてしまうところ、「テスト」というネーミングのせいだと思います。私たちが行っている「テストを周りの開発者に勧める方法」は次のようなものです。テストに通るたびにひとはしゃぎする(「うぉっ」「やった!」の一声だけでもOKです)休憩を取るときにこれ見よがしに「緑のバー」ののびた画面を表示したまま席を立つテストを語るときはニコニコする(しかし、ほどよい程度にしましょう。やり過ぎるとかえって危険です)「改造できますか?」と聞かれたら「テストをちゃんと作っていたので大丈夫です」と一言付け加える仕事を楽しくやる(これはテストをきちんと作ることで自然とできてしまいます。今回はテストの意義について考えてみました。Eclipseを使ったテストファーストを時間軸を追って実践していきます。テストを構築する際のTipsなどもご紹介する予定です。したか)メディアファイブ株式会社所属。XML,フレームワークを中心に開発業務に携わる。Javaのコミュニティー団体であるMobsterを主催。現在MonsterにてJavaベースのWikiシステム「MobWiki」を開発している。まさのり)メディアファイブ株式会社所属。XML、フレームワーク等の開発業務に携わる。Javaのコミュニティー団体である「Mobster」を縣と共に発起、運営。現在mobsterにてバグトラッキングシステム「mobbug」等を開発している。九州分科会」にも参加。ちなみにこの記事自身もCVSでバージョン管理し、縣と橋本とで共同所有されて書かれている。ぶすたー)福岡県福岡市を中心にJava言語を研究追求し、その成果物をWeb上に公開していく団体です。年齢・スキル・会社などを超えてボーダーレスに活動しております。電話サポートの保留音、世界の主流はクラシック——Genesys調査13カ国で実施した電話サポートの保留音に関する調査結果です。「フードロス」「廃プラスチック」に高い関心——CCC調査エコ・環境問題への関心や関連トピックスへの認知度などを調査しています。Inc.著作権はアイティメディア株式会社またはその記事の筆者に属します。(著作権について)当サイトに掲載されている記事や画像などの無断転載を禁止します。@IT情報マネジメント」「JOB@IT」「@ITハイブックス」「ITmedia」は、アイティメディア株式会社の登録商標です。当サイトに関するお問い合わせは「@ITへのお問い合わせ」をご覧ください。