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




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

第3回: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. グリーンの状態であること
  2. コーディング規約に準拠していること
  3. テストケースが妥当であること
  4. ソースコードが予期せぬ挙動をしないこと

表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テスト
  負荷テスト
  テスト駆動開発+α
Visual Studio 2005を活用した、テスト駆動開発とソフトウェア品質向上アプローチ
第1回 テストは開発者から利用者の視点へ
第2回 Visual Studio 2005で進めるテスト駆動開発
第3回 Visual Studio 2005 Team Systemで補うテスト駆動開発
第4回 チーム開発における品質向上策とVisual Studio 2005
開発ライフサイクルとVisual Studio 2005という選択肢
第1回 開発ライフサイクルが生むメリット
第2回 アーキテクチャ策定における有効性を探る
第3回 Visual Studio 2005による開発とテスト環境
第4回 チーム開発とVisual Studio 2005 Team Foundation Server
チーム開発ここまできた、個人からチームの生産性向上へ
第1回 Visual Studio 2005によるプロジェクトの進捗管理
第2回 Visual Studio 2005の変更管理の有効性
第3回 成果物の管理とプロジェクトのコミュニケーション向上
第4回 自動ビルドによるプログラムの品質・保守の有効性