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

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

単体テストとコードの設計の重要性

 単体テストを実装するためには、コードがそれを助けるように書かれていなくてはならない。単体テストを利用するには、自分のコードの書き方と、コードがなるべく1つの機能しか持たないようにする方法について、評価することを強いられることになる。例えば、ほかの領域や関数をいくつも呼び出すスパゲッティ関数を対象とした場合、その関数に対する単体テストを書くことにはあまり意味がなくなってしまう。もちろん、その関数の単体テストを書くことはできるが、そのテスト結果から何が得られるだろうか?その結果は、ほかの部分から分離されたコードのユニットのフィードバックとは言えないものになってしまう。

よい単体テストを書くには

 Steve Sanderson氏は、「Writing Good Unit Tests」(よい単体テストを書くには)というブログ記事で、よい単体テストを書くための素晴らしい手引きを提示している。以下は、同氏の説明の一部を要約したものだ。

  1. それぞれのテストは、ほかのあらゆるテストと直交するものにする。特定の振る舞いは、1つのテストでのみ指定されているようにする。
    • 不必要なアサーションは設定しない(あるいは、1つのテストにつき1つの論理的アサーションのみを設定する)。
    • 1度にコードの1つのユニットのみをテストする。
    • 外部のすべてのサービスや状態にはダミーを用いる。
    • 不必要な前提条件を避ける。
  2. 設定に対する単体テストは行わない。設定は、単なる設定であり、テスト対象にすべきコードのユニットではない。
  3. 単体テストに対しては、わかりやすく一貫性のある名前をつける。

デザインタウン

 私のお気に入りの1冊、「Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design」(邦題:「ビューティフルアーキテクチャ」)には、「デザインタウン」という名前のアプリケーションに対するケーススタディが出てくる。これによると、このアプリケーションの実装、メンテナンス展開の成功を形作る意思決定が、最初の段階で行われている。このケーススタディでは、望ましいコーディング慣習を促進し、アプリケーションのアーキテクチャを強固なものに保つ上で、単体テストが重要であることが強調されている。

結論

 単体テストを行う前に意思決定し、単体テストをしながら開発を進めることは、非常に困難な作業であるコードレビューの代わりに近いものになる。

 このやり方はTDDと合致するが、単体テストを使うという判断は、開発手法としてTDDを用いるかどうかとは関係なく行うべきだ。テストのもっとも重要な目的は、「作っているアプリケーション(あるいは艦上制御システム)が意図したとおりに動作することを、どのように確認するか?」という問いに答えることだ。単体テストは、この質問に対して、もっとも基本的なレベルで答えるものだ。

この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。原文へ

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