 |
|
| 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を中心としたシステム開発プロジェクトにてアーキテクト、トラブル対応、営業支援、などを主に担当しています。
|
|
|
|
|
|
