オープンソースの.NETツールを使って洗練されたビルド環境を作る

.NETプラットフォームで利用できるフリーのビルドツール

Visual Studio .NETを使ってテストプロジェクトをビルドする

　これでビルドプロダクトが1つできましたが、このビルドプロダクトを使ってできることは、想像以上にたくさんあります。それぞれのビルドを使ってできる中で最も重要なのは、ユニットテストを実行できることです。NAntを使えば、NUnitテストの実行を非常に簡単に統合することができます。ただし、まずテスト用の設備（テストフィクスチャ）をいくつか用意する必要があります。

1. ソリューション内で新しいクラスライブラリを作成し、「BuildingTest」と名前を付けます。
2. 「c:\devtools\nunit\bin\nunit.framework.dll」へのファイル参照を追加します。
3. BuildingBLへのプロジェクト参照を追加します。

　ユニットテストを書くと、ソフトウェア開発者はアプリケーションのさまざまな部分をテストする予防的な手段を実現できます。ユニットテストの結果を調べれば、システムのある部分に加えた変更が、システムのどこかほかの部分に影響を及ぼしていないかどうかを、迅速かつ簡単に判断することができます。正確なテストを行い、コードの品質を高く保てば、ユニットテストの効果が大幅にアップします。ユニットテストを統合する際の方針を計画する場合は、このことを念頭に置いておいてください。

　では、そろそろ何かコードを書きましょう。まず、クラスに[TestFixture]属性を追加します。次に、パブリックメソッドをいくつか追加し、[Test]属性を使ってそれぞれのメソッドにマークを付け、クラスのさまざまな面をテストします。これらのシンプルなメソッド1つ1つがクラスのいくつかの面をテストし、それらがすべて成功したら、テストは合格です。本稿で用意したサンプルコードには、サンプルテストも含まれています。

　クラスの外見は、次のようになります。

　これで、何かの処理を実行するクラスと、その処理の内容をテストするクラスが作成されたことになります。次は、テストの実行です。NUnitにはテストを実行するためのGUIが用意されています（GUIは、「c:\devtools\nunit\bin\nunit-gui.exe」です）。このツールを使えば、開発者は独自の個別テストを実行することができます（通常は、何らかのコードをより大きなプロジェクトにチェックインする前の時点で行います）。

　しかし、ビルドプロセスではこれらのテストをビルド時に実行できます。ビルド時というのは、プロジェクトのすべての部品が統合されているかどうかをテストするには最適なタイミングです。NAntには、NUnitをより簡単にビルドに追加するためのNunit2タスクが用意されています。

<!-- runUnitTests will run the nunit task on the test dlls -->
<target name="runUnitTests"
        description="Runs unit tests on specified dlls">
    <nunit2 failonerror="false" verbose="true">
        <formatter outputdir="${Build.OutputFolder}Latest\"
                   usefile="true" type="Xml" extension=".xml"/>
        <test>
            <assemblies basedir="${Build.OutputFolder}Latest\">
                <includes name="*Test.dll"/>
            </assemblies>
        </test>
    </nunit2>
</target>

　$変数はそれぞれ、上記のプロパティとして定義されています。<Nunit2はNUnitタスクを開始し、<formatterはNAntに対し、NUnitの出力をどう処理すべきかを指示します。この場合は、XMLフォーマットを指定しています。最後に、<testと<assembliesの各タスクは、テスト対象ファイルの処理を指定します。ここには、「*Test.dll」に一致するDLLファイルがすべて含まれます。

　これで、このビルドファイルを実行すると、ビルド済みプロジェクトができあがるだけでなく、ユニットテストの結果を伝える新しいXMLファイルも作成されます。この時点で、そのXMLファイルを利用し、おそらくはXSLTを使ってレポートを出したり、XMLを何らかのログにインポートできるようになっていますが、当面はその部分に触れずにおきます。このファイルを使ってできることについては、後でまた詳しく説明します。

FxCopを使ってビルド中にコーディング標準の妥当性を確認する

　簡単な方法

1. DOSプロンプトを開き、「c:\Projects\BuildingSolution」に移動
2. 「c:\devtools\nant\bin\nant.exe -buildfile:secondbuild.build.xml」を実行

　コードのレビューは、開発するプロジェクトの規模を問わず、非常に重要な作業です。コーディングの標準に準拠していることは重要ですが、コードをレビューする時間を使って標準への準拠をチェックし、準拠を強制するというのは厄介です。MicrosoftのFxCopを使えば、コーディングの標準に準拠するための時間を大幅に節約することができます。これにより、開発者はコードのレビューに専念でき、CamelとPascalにおける大文字小文字の区別などを論じる必要はなくなります。

　最初のステップは、FxCopを開き、FxCopファイルを1つ作成することです。

1. FxCopを開きます。
2. ［Project］、［Add Targets］の順にクリックします（または［Ctrl］＋［Shift］＋［A］キーを押します）。
3. ダイアログボックスで「c:\buildingsolution\Latest\buildingbl.dll」に移動します。
4. ［file］、［save］、［save as c:\projects\buildingsolution\buildingsolution.fxcop］の順にクリックします。

　こうすると、デフォルトのFxCop標準と突き合わせて妥当性を確認するためのFxCopファイルが1つ作成されます。FxCopは非常に柔軟で、開発者独自のコーディング標準に合わせてルールをカスタマイズすることもできます。

　これで、FxCopがビルドに追加できるようになりました。この時点では、NAntにはFxCop用の具体的なタスクがありませんが、<execタスクを使えば、FxCopをたやすくビルドに追加することができます。

<!-- runFxCop will run the fxcop file of the same name as
     the nant project -->
<target name="runFxCop">
    <exec program="c:\devtools\fxcop\fxcopcmd.exe" 
        commandline="/p:${nant.project.basedir}\${nant.project.name}
.fxcop /o:${Build.OutputFolder}Latest\fxcop-results.xml"
        failonerror="false"/>
</target>

　<execタスクを使えば、任意のコマンドラインアプリケーションを実行し、出力を集めることができます。この例では、FxCopのコマンドラインバージョンである「fxcopcmd.exe」を実行しています。テスト対象のDLLと、出力先となるXMLを用意してください。繰り返しますが、このファイルは後ほど重要になってきます。

APIドキュメンテーションの作成

　簡単な方法

1. DOSプロンプトを開き、「c:\Projects\BuildingSolution」に移動
2. 「c:\devtools\nant\bin\nant.exe -buildfile:thirdbuild.guild.xml」を実行

　ビルドプロセスによって、APIドキュメンテーションを作成するための魅力的な場所ができあがります。この機能は、NAntとNDocの両方に、直接組み込まれています。ドキュメンテーションをビルドごとに作成するのは、プロジェクトによっては適切ではない場合があります。ドキュメンテーションをいつ作成するかについても、各種のルール（たとえば「リリースビルドのみ」など）をたやすく適用することができます。

　C#のプロジェクトでは、コンパイラがビルド時にXMLドキュメンテーションを抽出することができます。このためには、BuildingBLプロジェクトの設定プロパティをチェックしてください。すると［XML Documentation Filename］というプロパティが見つかります。本稿に付属のプロジェクトでは、このプロパティを「BuildingBL.xml」に設定します。

　一方、VB .NETの開発者は、同じドキュメンテーションを作成するために、もう少し多くの手順を実行する必要があります。VB.DOCやVBCommentorのようなパッケージを使えば、同じAPIドキュメンテーションの生成を適用することができます。

　本稿で使用しているXMLファイルは、VS .NETでコンパイル時に生成されたものです。その設定をプロジェクトファイル内で指定すれば、NAntでもXMLファイルを使ったソリューションをビルドすることができます。しかし、ビルドごとにXMLドキュメンテーションを使うと、通常よりもビルドが低速になります。そこで、いくつかのオプションを調べてみましょう。1つは、ソリューションタスクの代わりにcscタスクを使うというもので、このオプションを使えば、doc引数を渡すことができます。もう1つは、xmlpeekとxmlpokeを使ってprojファイルを変更し、XMLドキュメンテーションのファイル名を指定するというものです。xmlpeekの探索（poke）タスクを使えば、XPath式を供給したり、XMLファイルから値を読み出すことができます。xmlpokeはその反対の処理を行い、ビルド時にXMLドキュメントを追加することができます。

　プロジェクトを「F5ビルド」してもXMLファイルが生成されるため、ビルド時のドキュメンテーション作成は簡単です。実際、NDocタスクは丸ごとNAntドキュメンテーションからコピーされたものです（ちなみに、このドキュメンテーションは非常に良質です）。

<!-- runCreateDocumentation will create msdn type documentation
     for the building solution -->
<target name="runCreateDocumentation"
        description="Will create documentation for Buidling Solution">
    <ndoc>
        <assemblies basedir="${Build.OutputFolder}Latest\">
            <includes name="BuildingBL.dll" />
        </assemblies>
        <summaries basedir="${Build.OutputFolder}Latest\">
            <includes name="BuildBL.xml" />
        </summaries>
        <documenters>
            <documenter name="MSDN">
                <property name="OutputDirectory"
                          value="${Build.OutputFolder}Latest\doc" />
                <property name="HtmlHelpName"
                          value="BuildingSolution"/>
                <property name="HtmlHelpCompilerFilename"
                          value="hhc.exe" />
                <property name="IncludeFavorites" value="False" />
                <property name="Title" value="BuildingSolution"/>
                <property name="SplitTOCs" value="False" />
                <property name="DefaulTOC" value="" />
                <property name="ShowVisualBasic" value="True" />
                <property name="ShowMissingSummaries" value="True" />
                <property name="ShowMissingRemarks" value="True" />
                <property name="ShowMissingParams" value="True" />
                <property name="ShowMissingReturns" value="True" />
                <property name="ShowMissingValues" value="True" />
                <property name="DocumentInternals" value="False" />
                <property name="DocumentProtected" value="True" />
                <property name="DocumentPrivates" value="False" />
                <property name="DocumentEmptyNamespaces"
                          value="False" />
                <property name="IncludeAssemblyVersion"
                          value="False" />
                <property name="CopyrightText"
                          value="iceglue for .net" />
                <property name="CopyrightHref"
                          value="http://www.iceglue.com" />
            </documenter>
        </documenters> 
    </ndoc>
</target>

　<ndoc>タスクでは、まず「どのDLLファイルとXMLファイルを使用するか」を指定する必要があります。まとまった複数のドキュメンテーションを作成する必要がある場合は、その旨をループ内で指定することができます。そうすると、長大なプロパティリストができあがります。これらのプロパティについては、NDocのリファレンスで詳しく説明されています。このリストによって、MSDNスタイルのchmファイルが、ビルドフォルダ内の/docディレクトリに作成されます。