連載：VSTSの単体テスト機能は本当に使えるのか？ 第2回 アジャイル開発者から見たVSTSテスト機能 太陽システム株式会社　中西 庸文 （Microsoft MVP 2006 - Solutions Architect） 2006/09/20

Page1 Page2 Page3 Page4 Page5

Back Issue

1 Team Systemのテスト機能の実際

　前回ではVisual Studio 2005 Team System（以下、VSTS）の単体テスト機能の概要について解説した。今回はアジャイル開発者の視点からこれらの機能について見ていく。

　VSTSはすでにアジャイル開発を行っている開発者にとって必要十分な機能を備えているのか。また、VSTSの単体テスト機能は.NETアジャイル開発者にとってすでに定番となっているNUnitから移行するほどのものなのか。

　まずはアジャイル開発のポイントについて簡単にまとめてみよう。

アジャイル開発に必要な基本スキル

　アジャイル開発に必要な基本スキルとして、筆者が特に重要視しているのが、「バージョン管理」「単体テスト」「自動化」である。この3つは、特にアジャイル開発に限定されたものではなく、開発者なら誰にでも必要となる基礎知識であり、ソフトウェアの健康（＝Software Health）を保つためにも欠かせないものである。

　もし、これらのスキルのうちのどれかが欠落しているようであれば、どこかで貴重な時間を無駄にしているはずである。

　例えばテスト駆動開発で単体テストを実施していたとしても、バージョン管理を適切に行わずにファイル・サーバ上に日付ごとのバックアップを取っていたり、定型的な繰り返し作業を自動化することなく手動で行っていたりするようでは、開発者が本来優先して取り組むべき重要で困難な問題の解決に割けるはずの時間の多くを無駄にしているといえる。

　これらのスキルを身に付けることは、自らを“躾”（しつけ）ることだと考え、ぜひとも進んで日ごろから実践していただきたい。

　それでは、3つの基本スキルについて簡単に説明しておこう。

■バージョン管理

　バージョン管理とは、バージョン管理ツールのリポジトリに、アプリケーションの開発時に作成されたソース・ファイルのすべての履歴（＝リビジョン）を格納することである。このためバージョン管理は、ソース・コード管理と呼ばれることもある。

　バージョン管理によってもたらされるメリットには、次のようなものがある。

• 複数の開発者が同じコードに対して適切に管理された方法でアクセスして作業を行える
• アプリケーションの任意のバージョンを復元できる
• アプリケーションの変更履歴を追跡できる
• メインストリームの開発を停止することなく、複数のリリース作業を同時に実行できる（＝ブランチによる並行開発）

■単体テスト

　単体テストとは、前回の記事でも説明したようにxUnitテスティング・フレームワークによって提供される自動化された単体テストのことであり、自動ビルド時にはアプリケーションの「自己テスト」としての役割も果たす。

　また、単体テストは“Developer Test”とも呼ばれており、通常のテスト以外にも次のようなバリエーションがある。

• Stub／Mock
  　ネットワーク、ファイル・システム、データベースなど、テストをセットアップするためのコストがかかる場合に、メモリ上でテストをシミュレートするためのクラスを用意して単体テストを実行する

• Debugging Test
  　バグを発見した際に、そのバグを再現するための単体テストを作成して失敗させ、そのテストを成功させることでバグを取り除く

• Learning Test
  　使ったことのないライブラリを利用して作業する際に、ライブラリの使用方法の学習を目的とした単体テストを記述する

• Assumption Test
  　特定のフレームワークなど外部ライブラリに依存した開発を行う際に、仕様の一部としてそのライブラリに期待する動作を単体テストとして記述しておく

　これらのバリエーションの詳細はt-wada（和田 卓人）氏による「デベロッパーテスティング〜ソフトウエア開発者の基礎体力」を参考にされたい。

■自動化

　自動化とは、コードのビルドおよびテストの実行から本番ソフトウェアの配布（必要に応じてインストーラの作成）までの繰り返し実行される作業を、手動で行わずにコンピュータに実行させることである。

　これは「トヨタ生産方式」でいうところの「自働化（automation with a human touch）」でもある。製品が正常に生産されている間は人は何も関知せず、異常によりストップしたときにだけ問題に迅速に対処する。つまり、単純作業は機械に任せ、機械にはできない（人が介入する必要のある）作業のみを人がやることで限られた時間を有効活用し、新たな価値を生み出すことが可能になる。

　自動化のために必要なことを以下に示す。

• バージョン管理
  　ソース・コードに対する変更を検出して自動ビルドを実行させるためにはバージョン管理ツールは必須である。バージョン管理ツールのリポジトリには、ビルドに必要なすべてのファイルを格納すべきである

• 自動テスト
  　自動化された単体テストは、コードの変更に対して何も壊れていないことを確認するための優れた自己テストとしての役割を果たす。ビルド・プロセスに自己テストの実行を含めると、バグを素早く効果的に発見することができる

• スクリプト化
  　ビルドの複雑な手続きを自動化するためには、ビルド・プロセスをスクリプト化して繰り返し実行できるようにしておく必要がある。ここでいうビルドとはIDE上から実行するビルド・プロセスのことではない。IDEがなくてもサーバ上でビルドを実行することができるようなマスター・ビルドのことである

• 異常検知
  　ビルドに異常が発生した場合に、電子メールやビルド結果を表示するWebページ、もっと直感的なところではパトランプ（緊急用の赤色灯）などを用いて開発者に素早く異常を知らせるための仕組みが必要である

VSTSにおけるアジャイル開発の実践

　VSTSでアジャイル開発を実践するには、先に述べた3つの基本スキルを実現するために、Team Foundation Serverと組み合わせることになる。

　ただし、VSTSの機能を用いずに、VS 2005単体と各種オープンソースのツールを活用することでもこれらのスキルを実現すうことは可能だ。ここではその方法も併せて紹介しておこう。

　どちらの方法を採用するにしても、物理コストや運用コスト、学習コストなど何らかのコストが発生するのは避けられないだろう。安全（この場合にはSoftware Health）とコストのトレード・オフを考えつつ、環境に応じて適切な方法を選択しなければならない。

■VSTSおよびTeam Foundation Serverでの実現

　まず、VSTSおよびTeam Foundation Serverで基本スキルを実現する方法を紹介しよう。

　この方法を採用するためには、開発マシン上のTeam Edition for Software Developers（以下、TE for Developer）もしくはTeam Edition for Software Testers（以下、TE for Tester）にTeam Foundation Serverのクライアントとなるためのチーム・エクスプローラがインストールされており、ネットワーク上にTeam Foundation Serverがセットアップされていることが前提条件となる。

　また、この方法が採用できればVS 2005のIDE上からほとんどの操作が実行可能で、Team Foundation Serverによって必要な情報が一元管理できるというメリットもある。

基本スキル	実現方法
バージョン管理	Team Foundation Serverのソース・コード管理ツールを使用するか、Visual SourceSafeを使用する。どちらのソース・コード管理ツールでもリポジトリへのアクセスはVS 2005のIDE上から実行できるが、ブランチやシェルブ（＝コードの一時的な共有）が提供されていてより強力なTeam Foundation Serverのソース・コード管理ツールの使用をお勧めする
単体テスト	VSTSのコード・テスト・ツールの単体テストを使用する。テストの実行と管理はVS 2005のIDE上ですべて実行できる
自動化	Team Foundation Serverのチーム・ビルドを使用する。自動ビルドはTeam Foundation Server上で実行され、ビルド結果はVS 2005のIDE上からも確認できる。自動ビルドでは単体テストの実施やコード・カバレッジの実行なども指定可能である。また、Team Foundation Serverは豊富なレポート表示機能を持っており、継続的インテグレーション・サーバとしての役割も果たす
VSTSおよびTeam Foundation Serverで実現する方法

　Team Foundation Serverで提供される各種機能については「Team Foundation ServerによるTeam System運用の実際」を参照されたい。

■オープンソースのツールでの実現

　前述のような恵まれた環境が整備されていることは、実際の開発の現場においてはまれではないだろうか。そのような環境がないからといって、基本スキルが実現できないわけではない。それぞれのスキルを実現するための基盤としてオープンソースのツールがすでに提供されているからだ。それらをVS 2005と組み合わせればよい。

　しかし、この方法を採用した場合にはそれぞれのツールの学習コストがどれも少し高めなのがデメリットでもある。ただしツールはすべて無償である。

基本スキル	実現方法
バージョン管理	現時点ではSubversionが有力なバージョン管理ツールである。Subversionのフロント・エンドとしては、Windowsのエクスプローラと直接統合されて動作することでリポジトリへのアクセスを提供するTortoiseSVNや、VS 2005のIDEと統合するためのプラグインであるAnkhSVNなどがある
単体テスト	NUnitやMbUnitを使用する。TE for DeveloperもしくはTE for Testerが利用できるのであれば、VSTSのコード・テスト・ツールの単体テストを使用してもよい
自動化	ビルド・スクリプトの作成はMSBuildを使用するか、NAntを使用する。NAntは.NET Framework 2.0がサポートされたNAnt 0.85 Release Candidate 4を使用すること。自動ビルドの定期実行およびビルド結果の参照には、継続的インテグレーション・サーバとしてCCNETを使用する
オープンソースのツールで実現する方法

　MSBuildについては「.NETビルド・エンジン『MSBuild』使いこなし術」および「ビルド・エンジン『MSBuild』を思いのままに操る技」を参照されたい。

　ここまででVSTSにおけるアジャイル開発の実践について簡単に説明したが、以前からテスト駆動開発を実践されている方なら、VSTSの単体テストとNUnitの違いが最も気になるところであろう。

　それでは、テスト駆動開発の観点においてVSTSの単体テストをNUnitと比較し、VSTSの単体テストが本当にNUnitからの移行に値するものであるかどうかを探っていくことにしよう。

INDEX
	VSTSの単体テスト機能は本当に使えるのか？
	第2回 アジャイル開発者から見たVSTSテスト機能
	1．VSTSにおけるアジャイル開発の実践
	2．VSTSの単体テストとNUnitとの比較（1）
	3．VSTSの単体テストとNUnitとの比較（2）
	4．VSTSの単体テストとNUnitとの比較（3）
	5．NUnitからVSTSのテスティング・フレームワークへの移行

　

「VSTSの単体テスト機能は本当に使えるのか？」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）