[ThinkIT] 第3回：Visual Studio 2005 Team Systemで補うテスト駆動開発 (1/4)

TOP＞プロジェクト管理＞はじめに

Visual Studio 2005を活用した、テスト駆動開発とソフトウェア品質向上アプローチ

第３回：Visual Studio 2005 Team Systemで補うテスト駆動開発
著者：日本ユニシス稲葉歩 2005/12/13

1 2 3 4 次のページ

はじめに

前回は機能・保守性に優れたソフトウェアを開発するために、Visual Studio 2005（以下、VS2005）Team Systemとテスト駆動開発が有効であることを検証しました。それで「開発はめでたく終了」となればこんなにうれしいことはないのですが、実際にはそうはいきません。

テスト駆動開発はあくまでも1人の担当者が開発をスムーズに進めるためのプロセスです。テスト駆動開発が終わったら、結合テスト／システムテストなどが待っています。今回は結合テスト／システムテストにおいて有効なVS2005 Team Systemの機能を紹介します。

カバレッジ分析

テスト駆動開発ではテストコードもソースコードも1人の開発者が担当します。その開発者が納品するテストコードやソースコードは必要十分なものでしょうか。不具合のある納品物では、安心して結合テストに進むこともできません。まずは納品物の検証、すなわち「受け入れ」をする必要があります。

受け入れの基準はプロジェクトによって様々だと思いますが、少なくとも表1にあげた基準を満たす必要があると考えられます。

グリーンの状態であること
コーディング規約に準拠していること
テストケースが妥当であること
ソースコードが予期せぬ挙動をしないこと

表1：受け入れの基準

納品物はテストコードとソースコードがペアになっています。1の検証には、受け入れ担当者がVS2005 Team Systemを使用してユニットテストを実行すればよいわけです。

前回、コーディング規約はガイドライン（注1）にそった内容にすることにしました。2の検証には、受け入れ担当者が納品物に対してコード分析を実行すればよいわけです。

※注1：前回紹介した「Design Guidelines for Class Library Developers」を指す。

テストケースが妥当であるということは、従来であれば仕様書の記述が正しいことを意味しますので、こればかりは人間が判断するしかないでしょう。3の検証には、受け入れ担当者がテストコードをレビューすることで十分に仕様が記述されていることを検証します。

「予期せぬ挙動」とは仕様に記述されていない動きです。つまり、テストされていないロジックがソースコードに存在し、テストケースが不足していることになります。4の検証のために、以下に紹介するカバレッジ分析の機能を利用して、テストコードの充足度をはかることが可能です。

カバレッジ分析の実行

カバレッジ分析を実行するためには、メインメニューから「Test → Edit Test Run Configurations → Local Test Run（localtestrun.testrunconfig）」を選択します。「Code Coverage」を選択し、カバレッジを取りたいアセンブリ（ここではソースコードを含んだアセンブリ）を選びます。次に「Apply」ボタンを選択し、「Close」ボタンをクリックします。

その後ユニットテストを実行すると、図1のように「Code Coverage Result」ウィンドウにはカバレッジの統計情報が表示され、ソースコードには「実行されたコード」「されなかったコード」が色分けされて表示されます。

図1：テストコードのカバレッジ
（画像をクリックすると別ウィンドウに拡大図を表示します）

前回作成したソースコード（注2）は、「郵便番号に該当する住所が存在しなかったら空白文字列を返す」実装になっていましたが、テストコードにはそのテストケースがありませんでした。つまり「予期せぬ動作」をするソースコードになっていたことになります。

※注2：前回リファクタリングで紹介したサンプルコードを参照してください。

カバレッジ分析の結果は100%であることが理想的ですが、純粋に100%にすることが現実的でないケースが考えられます。先ほど紹介した通り、カバレッジ分析は選択したアセンブリに対して実施されるため、アセンブリに含まれるすべてのコードが対象となります。

つまり、VS2005 Team Systemを使用して自動生成したDataSetやWebサービスプロキシのコードも対象となります。カバレッジ分析の結果が100%となることを制約すると、これらのコードに対するテストコードを実装する必要があります。そうすると自動生成ツールを使うほど、かえって開発者の負荷が増大してしまいかねません。目指すべきは「開発者が作成したソースコードのカバレッジ分析の結果が100%となること」であり、自動生成コードに対するテストは必要に応じて行う、というのが現実的でしょう。

1 2 3 4 次のページ

著者プロフィール
日本ユニシス株式会社稲葉歩
.NETテクノロジコンサルティング所属
.NET Frameworkを中心としたシステム開発プロジェクトにてアーキテクト、トラブル対応、営業支援、などを主に担当しています。

INDEX
第3回：Visual Studio 2005 Team Systemで補うテスト駆動開発
	はじめに
	Webテスト
	負荷テスト
	テスト駆動開発＋α