Visual Studio 2005 Team Systemで補うテスト駆動開発

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

稲葉 歩

2005年12月13日 20:00

はじめに

前回は機能・保守性に優れたソフトウェアを開発するために、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%となること」であり、自動生成コードに対するテストは必要に応じて行う、というのが現実的でしょう。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30