よい単体テストの特徴と、書くためのヒント

文:Erica Henson 翻訳校正:石橋啓一郎
2010-03-23 07:00:00
  • このエントリーをはてなブックマークに追加

 Alan Cooper氏著の「The Inmates Are Running the Asylum」(邦題「コンピュータは、むずかしすぎて使えない!」)で、同氏は「軍艦にコンピュータが導入されたら何が起こるか」という問いを発している。同氏は、米国のミサイル巡洋艦ヨークタウンが大西洋で艦隊行動を行っていた際に起きた事件を例に挙げた。その時、海軍の技術者は燃料バルブを調整しており、艦上管理コンピュータの1つにゼロを入力した。すると、プログラムは入力されたゼロの値で別の数を割ろうとして(この解は数学では未定義となる)、ドカン!制御システム全体が完全にクラッシュしてしまい、海岸に曳航できるようになるまで、何時間も水上で立ち往生してしまったのだ。

 この艦の管理システム全体が、設置前にはまったくテストされず、なんらかの形のテスト運用も行われなかったというのは考えにくいことだ。このシナリオは、「本当に?どうして分からなかった?」ということが実際に起こりうるということを示すものだ。もし、この運命のゼロが入力されたとき、この艦が戦闘中だったらどうなっていただろうか。

 前述の本では設計全体について扱っているが、このコラムではテストに焦点を当てることにする。ゼロ除算などというものは、どんな関数に対してもテストされ、発見されているべきものだ。もし前もって何らかの形の単体テストが行われていたら、当然、このような致命的な計算エラーは早い段階で判明していたはずだ。

 それこそが、単体テストが実施される理由だ。MSDNで定義されているとおり、単体テストの主な目標は、アプリケーションのテスト可能な最小ユニットを取り出して残りのコードから分離し、それが予定通りの動作をするかどうかを調べることだ。そして全体としても、テスト駆動開発(TDD)の見方でも、単体テストの価値は、テストをすることで、開発プロセスの早い段階で高い割合の欠陥が発見されるということによって、証明されている。

よい単体テストの特徴

 単体テストに対する一般的なアプローチでは、ドライバとスタブを書く必要がある。ドライバは、呼び出し側のユニットをシミュレートし、スタブは呼び出されるユニットをシミュレートするものだ。Roy Osherove氏の「The Art of Unit Testing」(単体テストの技術)第1章では、よい単体テストの特徴を次のように説明している。

  • 単体テストは、自動化され、反復実行できるものであるべきだ。
  • 単体テストは実装しやすいものであるべきだ。
  • 一度単体テストが記述されたら、将来の使用に備えて残しておかれるべきだ。
  • 誰でもその単体テストを実行できるべきだ。
  • 単体テストはボタン1つで実行できるべきだ
  • 単体テストは素早く実行できるべきだ。

 単体テストをどう書き始めていいかよく分からないなら、これまで自分が書いてきたテストに関して、次のような質問をしてみるといいだろう。

  • 自分が2週間前、2カ月前、2年前に書いた単体テストを実行して、その結果を得ることができるか?
  • 自分のチームのどのメンバーであっても、自分が2カ月前に書いた単体テストを実行して結果を得ることができるか?
  • 自分が書いた単体テストは、数分以内にすべて実行することができるか?
  • 自分が書いた単体テストは、ボタンを押すだけですべて実行することができるか?
  • 基本的な単体テストを、数分程度で書くことが出来るか?
  •  これらの質問の答えが1つでも「ノー」であれば、実装しているものは単体テストではない可能性が高い。

  • 新着記事
  • 特集
  • ブログ
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]