Jenkinsを使って、コミットしたソースを自動でビルドするというところはクリアしました。 次は、テストコードを書いて、自動でビルドをした後そのテストコードを実行させてみます。
とりあえずNUnitをインストールします。verは2.6.1です。 それから開発環境から使えるように外部ツールの設定をします。
- [Visual C#] Visual C# 2010 Express からNUnitを起動する方法 - kurukuru-papaの日記 http://d.hatena.ne.jp/kurukuru-papa/20120902/1346598542 こちらの説明が完璧です。 64bit環境でNUnitを使おうとするときの場合分けまできっちり書いてくれています。 64bit環境でソリューションのプラットフォームをx86を選んでいる状態で、nunit.exeを起動起動すると、
こういうエラーメッセージが出ます。 x86のプロジェクトの場合は、nunit-x86.exeを使わないといけないんですね。ややこしいです。
あとはもう、ggrksっていうぐらい情報がありますので、どうやってテストコードを書いてテストしていくかっていうのをごくごく単純なプロジェクトを使って一通りやってみます。 問題なくローカルでテストコードが動くようになれば、後はこれをJenkins氏に自動でやってくれるように設定すればいいわけです。
Jenkinsのプロジェクト設定-ビルドのところで、まずはMSBuildが動いてビルドが行われるようにした後、「ビルド手順の追加」で「Windowsバッチコマンドの実行」を選ぶと、複数行のテキストボックスが出てきますので、そこにバッチファイルを書くのと同じ手順で、NUnitが実行されるように書けばOKですね。
"C:\Program Files (x86)\NUnit 2.6.1\bin\nunit-console.exe" MyClassLibraryTest\bin\Debug\MyClassLibraryTest.dll /xml=nunit-result.xml
こんな感じになります。
一度MSBuildだけ設定してJenkins上でビルドを成功させておけば、Windows環境側のワークスペースフォルダにファイルが残っていますので、 先にコマンドプロンプトでどう書けばちゃんと実行されるか試してみればよいですね。 ちなみに、Jenkinsでバッチコマンドが実行される際は、そのプロジェクトのワークスペースがカレントディレクトリになりますので、そこを基準に動くように書くとよいでしょう。 これで問題なく動いて、ワークスペースにnunit-result.xmlができるようになれば、とりあえずビルドされたらもれなく自動テストしてくれるようになります。
で、xmlがぽろんと出てくるだけではテストが通ったんだかよくわかりませんので、 Jenkinsに「NUnit Plugin(https://wiki.jenkins-ci.org/display/JENKINS/NUnit+Plugin)」を入れて、Jenkinsのプロジェクト設定の「ビルド後の処理」に「Publish NUnit test result report」を追加して、「Test report XMLs」にコマンドラインの時に指定した、「nunit-result.xml」と書いておきます。
こういう設定をしておくと、Jenkinsのプロジェクトページに、
こういうメニューが追加され、
こんな感じでテスト結果が表示されます。 クリックしていくと、メソッドの単位までテストの状況を見ることができます。 ただ、 ちょっと表示が気になるのは、テストコード側でTestCase Attributeを使っている場合の表示がなんか変に分離されちゃっててわかりづらいのですね。 上の画像では、 (root)というところに2つ、MyClassLibraryTestというところに2つテストがありますが、実際書いているテストコードは、MyClassLibraryTestの中に3つのテストメソッド、そのうちの一つがTestCaseで2つの引数で実行されるメソッドになっていて、合計4つ入っているはずなんですね。 まだこのへんは未対応なんですかね。 でもまあ、実際の運用の場合、プログラミング作業をして自分でテストを走らせてからソースのコミットをするんでしょうから、ここでの表示が作業に直接影響することはないと思われます。
さて、これでテストコードを書いて、実装をして、ソースをコミットしたら、Jenkinsがビルドしてくれて自動テストを一通り実行してレポートしてくれる、という流れができあがりました。 でもまだまだ課題が出てきます。
NUnitのテストと連動してOpenCoverによるコードカバレッジを行うようにすれば、よりテストの精度を上げていくことができますし、StyleCopでソースコードの記述作法をチェックするようにすれば、コーディングのばらつきを抑えることができます。 FxCopという実装上のルールをチェックするのもありますね。でもこれは指摘内容が難しくて、まず何を指摘されているのか理解するのに時間が必要になり、それを理解した後でも「じゃあどう実装すればいい感じなんだろう」というのを模索するのにさらに時間が必要になり、相当な時間泥棒になりますので見送るか、できるだけ限定的なルールに絞ってやってみる化ぐらいでしょうかね。
あともうちょっと実運用寄りの作業としては、ビルドした成果物を元にデプロイするだとか、SCMにコミットするとか、ドキュメントを生成したりとかもありますね。 そして、ここまでまだALMinium(Redmine)の出番が、svnにリポジトリを作るときぐらいにしかないという状況です。コミットする際にチケット番号を入れて関連づけたり等の基本的なところはもとより、Jenkinsとの連携も模索しないといけません。
あぁ、果てしない……