Team System における単体テストとポリシーの徹底による品質の作りこみ

こんにちは。 前回 に引き続き単体テスト関連です。今回は、単体テストを単に実行する、もしくは、自発的に実行するだけではなく、単体テストの実行をプロジェクトのポリシー（方針、ルール）として徹底することができるということを書きます。

Team System はその名の通り、システムで、言ってみればソフトウェア開発における IT システムを指しています。すなわち、単体で、個々人が使うツールとしての側面だけでなく、チームで使う開発基盤としてのシステムの側面があるということです。

単体テストの機能は、Team Edition for Software Developers, Team Edition for Software Testers (一部は、Team Edition for Database Professionals にも） で利用できるのですが、主な利用者はプログラムコードを書く人、すなわち、開発者になります。

開発者は、プログラムコードを書くときに（コードを書く前後ですね）、単体テストのコードも書きます。

さて、ソフトウェアの開発では変更がつきものです。残念ですが、バグは必ず発生しますし、仕様の変更もあります。プログラムコードは、一度書いたらそれで完了ではなく、変更をせざるをえない宿命をおっています。

（当然ですが、バグや仕様変更は、しかるべき方法で登録され、実施の意思決定がなされ、コードの変更へ・・・といくわけですが今回は割愛します）

プログラムコードを変更した後で、問題になるのは、「そのプログラムコードが適切に変更されているのか？」、「その変更で、他の機能に損失を与えていないだろうか？」をチェックすることです。単体テストを的確に実施していくことで、コードレベルでの品質を作りこんでいくことができます。しかしながら、変更に対してのテストを怠ると今まで作りこんできた品質を失ってしまう危険性があります。

開発者は基本的に自分の仕事にプライドをもっていますので、自分が行った変更に対しての責任をもつ傾向にあります。確実に修正箇所をデバッグし、確認することでしょう。単体テストも実施するでしょう。しかし、忙しさのあまりついテストの実施を忘れてしまうこともあるでしょう（そもそも品質に対する意識はバラツキがあるのも事実で、テストなんかしないという人もいますよね？）。また、自分が変更した箇所については目が行き届きますが、それが影響するであろう他の機能の確認（単体テスト）まではいきつかないかもしれません。

Team System では、チーム開発基盤システムである Team Foundation Server を活用することで、単体テストの確実な実施により、変更による品質の損失を未然に防ぐことができます。

プログラムコードに変更した後には、通常は、ソフトウェア構成管理システム（ここでは Team Foundation Server がその役割も担っています）で管理されたリポジトリにプログラムコードを反映する（これをチェックインするといいます）必要があります。チェックインしないと、その変更されたコードは、いつまでもその開発者の手元にしかなく、チームで使用することができないことになります（「そんなことするか？」と思うかもしれませんが、実際にはよくある問題です。リリース間際まで自分の手元で変更したコードを温めておいて、いざ結合したら・・・動かない・・・なんてことが・・・）。

Team Foundation Server では、チェックインポリシーというものがプロジェクト単位で設定できます。そのポリシーとして指定した単体テストがOKでないとチェックインをさせないという設定ができます。

これにより、どんなに忙しい開発者も、そして、品質に意識の高くない開発者も忘れることなく（怠けることなく）単体テストを実施することを意識することができるようになります。

 
Team Foundation Server でのチェックインポリシーの設定画面

（だいぶ長い投稿になってきましたが・・・）問題は、早期発見がベストです。コードを変更したときに、いかに問題を見つけ、その場で対処できるかにより、その後のバグの発生率やそれによって起こるより多くのプロジェクトの混乱を未然に防ぐことができるようになります（遅い時期に発見したら・・・まずどんな問題か理解し、どのコードに起因するか分析し、それがいつ書かれたか分析し、それで対処するわけですが、はたしてそれで他の改修されたはずのバグに影響がないかどうか・・・考えるだけでも頭が痛いですよね？）。

Team Foundation Server では、テストポリシーだけではなく、コード分析の実施、作業項目との関連付けをポリシーとして設定できます。また、第三者によるコードレビューの実施などをチェックイン メモとして残すこともできます。

このように Team System では、品質を作りこむための仕組みがいくつも備えられてあり、それらは、日々の開発で作成してきた成果物（単体テストコードとか）を利用することで成り立っているため、品質の維持・向上と開発生産性向上のどちらのニーズにも答えることができる環境を作っていくことができます。

※今回の投稿は、Visual Studio 2005 ベースで書きました。

関連する投稿一覧：

• Road to Tech・Ed 2007 Yokohama: T3-308 Visual Studio 2008 における Team System の新機能
• Team System における単体テスト

ながさわ

Comments

• Anonymous
  July 09, 2007
  PingBack from http://blogs.msdn.com/tomohn/archive/2007/07/10/team-system.aspx

• Anonymous
  November 04, 2007
  こんにちは。今日も Tech・Ed に向けた Team System の話題を書きたいと思いますが、以前からたまに書いている VS 2008 Petit-Review としてお送りします。 というのも、単体テスト機能は、VS

• Anonymous
  December 08, 2007
  MSDN オフラインセミナー 全国ツアー ＜チーム開発編＞にご参加いただきありがとうございました。 このページでは、セミナーでご覧いただいたデモンストレーションでのオペレーションやテクニックについて主に、過去、そしてこれからこのブログに投稿する（した）ものを紹介する形でご紹介いたします。