Compartilhar via

【VSTS|TIPS】PathToWebRoot 環境変数とASP.NET の単体テストおよびWebテスト

  • Artigo

こんにちは。先日の 【VSTS|TIPS】単体テストを用いたパフォーマンスのテスト という投稿において、

ちなみに、この単体テストの環境は ASP.NET でテストは ASP.NET 開発サーバー上で実行される設定になっています。そのあたりの属性の設定については別途投稿します。

と書きました。今回は、その話です。先日の投稿をご覧になっていない方はぜひそちらをご覧になった上で読んでください（読まなくてもご理解は頂けると思いますが）。

VSTS では単体テストを想定したターゲット上で実行することが可能です。たとえば、Web アプリケーションで実行されるクラスライブラリの単体テストであれば、ASP.NET 上でのテスト実施となり、モバイル アプリケーションであればWindows Mobile 上（の.NET Compact Framework）でのテスト実施（※ モバイル上での単体テスト実施は VS(TS) 2008 の新機能です）となるわけです。

ASP.NET のアプリケーションであれば、IIS 上であっても、ASP.NET 開発サーバー上であってもよいわけですが、特に単体テストとなると、開発者が気軽に実行できる ASP.NET 開発サーバーを利用するのがやりやすいでしょう。そこで登場するのが、PathToWebRoot という環境変数です。これを用いることで、ASP.NET アプリケーションのWeb ルートとなるフォルダを指定することができます。先日の投稿だと、テストメソッドに付加されている属性の、

[HostType("ASP.NET")] 
[AspNetDevelopmentServerHost("%PathToWebRoot%\\Fabrikam", "/")]
[UrlToTest("https://localhost/")]

という部分がこれらに関連するものになります。HostType 属性ではホストするタイプを指定します。今回は ASP.NET となります。 AspNetDevelopmentServerHost 属性では、ASP.NET 開発サーバーで実行する Web アプリケーションのパスとルートを指定します。 UrlToTest 属性では、アクセスする URL を指定します。

※ ちなみに上記の属性は、単体テストの作成を実施すると自動で生成されますのでなーんにも気にしなくてもいいです。

※ UrlToTest にはポートまで指定することができます。上記のようにポートを指定しないと動的にあいているポートで Web サーバーを起動してくれます。

AspNetDevelopmentServerHost では、別に環境変数を使わずにダイレクトに記述してもかまいません。しかし、それはお勧めをしません。理由は、テストの再利用、再実行を考慮したいからです。

直接指定をしてしまうと、このテストを記述した開発者Aの環境では問題なく動作しますが、プロジェクトを配置した場所が異なる開発者Bの環境では、動作しない、動作させるには、この属性の値を変更しなければならなくなります。

では、この PathToWebRoot 環境変数は、どこで定義するのかというと、OS の環境変数でも定義することはできますが、Visual Studio の [ツール｜オプション] で設定することができます。スクリーンショットで見ていただくとわかりやすいです：

image

各開発者の環境に応じてこの設定をしていただくだけでテストコードに手を入れることなく、テストを確実に実行することができるようになります。

この設定は、Web テストでも有効です。Web テストでは、記録した際の Web サーバーの情報をパラメータ化することができます。下記のような感じです：

image

通常は、Web テストですので、テスト環境の Webサーバーは確定しているため、この設定を行う必要がないことが多いですが、ここでも ASP.NET 開発サーバーを設定することができます。ここでも PathToWebRoot 環境変数を使うことができるため、下のスクリーンショットのような設定ができます：

image

さて、この環境変数による設定は、上記にあげたようなメリットがありますが、実はビルド時のスモークテスト（または、BVT: Build Verification Test）を実施する際により、効果を発揮します。 Team Foundation Server の機能でビルド時に、自動でコード分析や指定した単体テストや Web テストを実行することができます（もちろん実行するだけではなく、成否を判断し、ビルドの品質を示してくれます）。このときには、通常、特定のフォルダ以下にビルド生成物が作成され、Web アプリケーションの場合は、Web サイトに必要なファイル一式も特定のフォルダに配置されます（その環境を用いて BVT が実行されるわけですね）。

このビルド生成物が配置される場所ですが、通常、ビルドするごとにビルドの識別子が付いたフォルダが作成されます。たとえば、Fabrikam_20071006.1 といった感じのものです。要するにビルドするたびにフォルダが異なるということになります。

継続的インテグレーションを実践する場合は、チェックインが発生するたび、または、ある一定期間を経て、ビルドが実行されますので、ビルド実行時にビルドIDがつき、その単位でフォルダが作成されるのは非常に理にかなっています。

しかし、BVT で実行される単体テストや Web テストからすると Web ルートのパスが定まらないことになり、困った事態になります。しかし、PathToWebRoot を使用しておくと、Team Foundation Server が ビルド時に配置されたフォルダをこの PathToWebRoot に自動設定し、確実にその時にビルドした生成物を利用した BVT を実施してくれます。

かなり、長い投稿になってきましたが、要するに今回のポイントは、BVT で利用する単体テストや Web テストなら、PathToWebRoot をうまく使ってみてくださいということになります（＾＾）

Microsoft On では、こういったところの話もするつもりです。

ながさわ

Comments

  • Anonymous
    October 04, 2007
    PingBack from http://www.artofbam.com/wordpress/?p=5158

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