Systemとテスト駆動開発が有効であることを検証しました。それで「開発はめでたく終了」となればこんなにうれしいことはないのですが、実際にはそうはいきません。テスト駆動開発はあくまでも1人の担当者が開発をスムーズに進めるためのプロセスです。テスト駆動開発が終わったら、結合テスト/システムテストなどが待っています。Systemの機能を紹介します。カバレッジ分析テスト駆動開発ではテストコードもソースコードも1人の開発者が担当します。その開発者が納品するテストコードやソースコードは必要十分なものでしょうか。不具合のある納品物では、安心して結合テストに進むこともできません。納品物の検証、すなわち「受け入れ」をする必要があります。受け入れの基準はプロジェクトによって様々だと思いますが、少なくとも表1にあげた基準を満たす必要があると考えられます。納品物はテストコードとソースコードがペアになっています。Systemを使用してユニットテストを実行すればよいわけです。前回、コーディング規約はガイドライン(注1)にそった内容にすることにしました。2の検証には、受け入れ担当者が納品物に対してコード分析を実行すればよいわけです。Developers」を指す。テストケースが妥当であるということは、従来であれば仕様書の記述が正しいことを意味しますので、こればかりは人間が判断するしかないでしょう。3の検証には、受け入れ担当者がテストコードをレビューすることで十分に仕様が記述されていることを検証します。「予期せぬ挙動」とは仕様に記述されていない動きです。テストされていないロジックがソースコードに存在し、テストケースが不足していることになります。4の検証のために、以下に紹介するカバレッジ分析の機能を利用して、テストコードの充足度をはかることが可能です。Run(localtestrun.testrunconfig)」を選択します。Coverage」を選択し、カバレッジを取りたいアセンブリ(ここではソースコードを含んだアセンブリ)を選びます。次に「Apply」ボタンを選択し、「Close」ボタンをクリックします。Result」ウィンドウにはカバレッジの統計情報が表示され、ソースコードには「実行されたコード」「されなかったコード」が色分けされて表示されます。図1:テストコードのカバレッジ(画像をクリックすると別ウィンドウに拡大図を表示します)前回作成したソースコード(注2)は、「郵便番号に該当する住所が存在しなかったら空白文字列を返す」実装になっていましたが、テストコードにはそのテストケースがありませんでした。「予期せぬ動作」をするソースコードになっていたことになります。前回リファクタリングで紹介したサンプルコードを参照してください。カバレッジ分析の結果は100%であることが理想的ですが、純粋に100%にすることが現実的でないケースが考えられます。先ほど紹介した通り、カバレッジ分析は選択したアセンブリに対して実施されるため、アセンブリに含まれるすべてのコードが対象となります。Systemを使用して自動生成したDataSetやWebサービスプロキシのコードも対象となります。カバレッジ分析の結果が100%となることを制約すると、これらのコードに対するテストコードを実装する必要があります。すると自動生成ツールを使うほど、かえって開発者の負荷が増大してしまいかねません。目指すべきは「開発者が作成したソースコードのカバレッジ分析の結果が100%となること」であり、自動生成コードに対するテストは必要に応じて行う、というのが現実的でしょう。Frameworkを中心としたシステム開発プロジェクトにてアーキテクト、トラブル対応、営業支援、などを主に担当しています。この記事の評価をお聞かせくださいボタンをクリックしますとウインドウが開きます。