CruiseControl.NET設置

1. 自動 Test と CruiseControl.NET Kuniaki IGARASHI 2006.8.21 http://igarashikuniaki.net/

2. 目次 各種テストの向き不向き 自動テストのメリット 自動テストツール CruiseConterol.NET 自動テストの始め方 参考文献 目標 みなさんが自動テストを始める際の最初の一歩をお手伝い

3. ところで、 テストを行う理由はなんでしょうか？ 不具合を可及的速やかに発見したいから。 （たぶん）

4. バグ早期発見のメリット 理由 コスト バグ修正にとりかかるまでの時間が長くなればなるほど、修正にかかるコストは（時間においても金額においても）高くなる スケジュール見積もり バグが存在している場合、スケジュールの見積もりは非常に困難。既存のバグを修正する時間よりも、新機能を実装する時間の方が遙かに見積もりし易い ゼロ欠陥法 ( 某 M$ 社 ) 「いかなる場合でも新しいコードを書く前に バグを取り除くことを最優先とする」 -> バグを発見する手段の 1 つが テスト である。

5. テストいろいろ UnitTest 主にメソッド単位のテスト。コード修正が行われるごとに回す。 バグ発見までの時間が短い 。 定期自動 Test 大量 のテストデータに関してテストを回す。 毎日実行することでバグが入り込んだタイミングがわかる。 人の手によるテスト 万能 だが、時間と手間がかかる。 テストには様々な種類がある 特徴を理解して 適材適所 のテストを行うと効果大

6. UnitTest メソッドを実行し、 戻り値、副作用が妥当であることを確認するテスト ツール : CppUnit, JUnit, NUnit など CAddition cadd; // 引数の和を返し、メンバ変数 m_lastResult に結果を格納するクラス int result = cadd.arg2(2,3); // テスト対象のメソッドを実行して CPPUNIT_ASSERT_EQUAL((int) 5, result); // 結果を確認 CPPUNIT_ASSERT_EQUAL((int) 5, cadd.m_lastResult); // 結果を確認 UnitTest の Code 例 閾値に関する UnitTest をしっかり書けば、 バグの出やすい閾値付近でのバグ発生率減少 リファクタリング時には UnitTest は必須

7. UnitTest – テスト駆動開発 メリット テストコードを書くことで仕様が固まる インターフェイスの曖昧さが解消 テストし易いコードを書ける テスト駆動開発 実装する前にテストを書く

8. 定期自動テスト メリット たくさんのテストを回すことができる バグが入り込んだタイミングがわかる 実行コストが非常に安価 (PC1 台から可 ) 定期的にビルドを行い、 あらかじめ記述したテストスケジュールを実行する

9. 常時結合 メリット リポジトリ上ソースのビルド失敗を早期発見 CVS add 忘れやソリューション構成変更忘れなどを早期検出可能。 他の開発者への影響を最小限で防ぐ -> リポジトリ上のソースがビルドできない場合、 時差のある 2 拠点開発では最悪丸 1 日仕事不能 バグ発生箇所の追求が容易 ビルドアーカイブを保管することで、 過去のある不明な時点で発生したバグを二分検索可能 テスト担当とのスムースな連携 テスト担当者が常に最新のビルドを手にいれることができる 定期的にテストを行うためには、 常時 、 自動 でビルド ( 結合 ) する必要があります。

10. 定期自動テストのメリット デイリーテストの実際の成果 お行儀の悪い入力で エラー処理が不適切 なのを発見 外部製 library 置き換えによる 挙動変更 に気づく 実装した場所とは違う場所への 副作用 を発見 出力ファイルの差分をとることで発覚した 不定値問題 過去に不具合のあった入力をテストし 不具合再発防止

11. デイリーテストってばすげー！ ここまでのお話で、 デイリーテストをやってみようかなと、ちょっと思ったり。 デイリーテストを導入したいですか？ Yes : これから具体的な方法を説明します。 No : 大人の対応をお願いします。

12. CruiseControl.NET 概要 OpenSource の定期テスト実行ツール (Apache Software License, BSD License) 定期的なビルド、テストが実行可能 Multi Platform 対応 .NET 環境の CruiseControl.NET JAVA 環境の CruiseControl CruiseControl.NET(CC.NET) 常時結合ツールの 1 つ

13. CruiseControl.NET で できること 定期的なコマンド実行 定期的なソース取得、差分確認 定期的なビルド メール、web、アプリケーションでのビルド結果報告 複数マシンでの分散ビルド環境構築 パトライトでエラー時に警告するシステムを 構築している人もいます。

14. CruiseControl.NET を使う 6 つの理由 毎日テストを実行することにより、 直前 24 時間の新規実装で発生したバグを発見 できます 別環境でビルドすることで CVS add 忘れなどを早期発見 できます エラー処理やタイムアウトが可能 (bat ファイルやスクリプトでは途中で処理が止まってしまった場合に後続の処理まで影響を受ける ) 複数マシンでの 分散ビルドが可能 MulitPlatform 展開 する場合に、テストパターンの書き換えが容易 (Path の書き換え程度 ) テスト OK によって得られる 安心感 - Priceless

15. スクリーンショット Mail でのビルド結果レポート Web でのビルド結果レポート

16. 動作環境 All 32-bit MS Windows (95/98/NT/2000/XP) Visual Studio .NET CVS Client (CVSを使用する場合) IIS (Webレポートを使用する場合) SMTP (メールレポートを使用する場合)

17. 対応ソース管理システム VSS, CVS, Subversion 他

18. インストール - IIS ContorolPanel -> プログラムの追加と削除 -> Windows コンポーネントの追加と削除 より インターネットインフォメーションサービス (IIS) をインストールします。 http でアクセスできるように設定してください。 ファイアーウォールの設定にも注意。

19. インストール - CC.NET http://sourceforge.net/projects/ccnet/ から Download してインストールしてください。 注意点： Web レポート機能を使う場合は、 IIS を先にインストールした方が設定が楽です。

20. インストール – IIS の設定 管理ツールのインターネットインフォメーションサービスで CC.NET web dashbord が加えられていることを確認してください。 また、 asp.net(aspnet_client) も必要です。 入っていない場合は以下のコマンドを実行してインストールしてください。 > %windir%\Microsoft.NET\Framework\v1.1.xxxx\aspnet_regiis.exe -i xxxx にはインストールされたバージョンが入ります。

21. Windowsサービス設定 ■ Windows サービスの起動設定 ・デフォルトでは手動起動の設定となっているので、自動起動に変更 ・ログオンの項目で適切なユーザーを指定しないと、認証ができず CVS の実行で失敗します。 ・ CC.NET サービスが起動していると、コマンドラインからは実行できないので注意。 （ CC.NET は 1 つしか起動できない。） ■ コマンドラインから手動で起動する場合 > [CruiseControl.NET Path]\server\ccnet.exe -config:ccnet.config ■ CVS 認証 ・サービスで指定したユーザーで、 CVS login コマンドを実行して認証をしておきます。 > cvs.exe -d :pserver:[user]:[repository] login

22. CC.NET 設定ファイル ビルドの指示は以下の xml ファイルに記述します。 C:\Program Files\CruiseControl.NET\server\ccnet.config --- 例 ( 概略 )--- <5 分ごとに CVS 監視 > < 変更があれば以下のタスクを実行 > < ソースディレクトリを削除 > <CVS CheckOut> <Build> <Mail 送信 > Examples フォルダ以下に設定ファイルの例が置いてあります。

23. CC.NET 設定ファイル <project name=&quot;BuildProject&quot;> <name> BuildProject </name> <workingDirectory>D:\CruiseControlWork\Src</workingDirectory> <artifactDirectory>D:\CruiseControlWork\Src</artifactDirectory> <modificationDelaySeconds>60</modificationDelaySeconds> <publishExceptions>true</publishExceptions> workingDirectory : ソースをチェックアウトするパス artifactDirectory : ビルドログを格納するパス modificationDelaySeconds : 最後のチェックインから x 秒間はビルドを開始しない publishExceptions : CVS などが応答しない場合の Exception エラーを通知

24. CC.NET 設定ファイル トリガー各種 Interval Trigger <intervalTrigger name=&quot;continuous&quot; seconds=&quot;30&quot; buildCondition=&quot;IfModificationExists&quot;/> 30 秒ごとにソースリポジトリを監視、変更があればタスク実行 Schedule Trigger <scheduleTrigger time=&quot;23:30&quot; buildCondition=&quot;ForceBuild“/> 決まった時間にタスク実行 Url Trigger <urlTrigger url=&quot;http://server/page.html&quot; seconds=&quot;30&quot; buildCondition=&quot;IfModificationExists&quot;/> URL で指定したファイルを監視、変更があればタスク実行 Project Trigger <projectTrigger serverUri=&quot;tcp://server:21234/CruiseManager.rem&quot; project=&quot;Server“/> 他の CC.NET プロジェクトの状態を監視、条件にあえばタスク実行

25. CC.NET 設定ファイル Visual Studio Task ｰ VS でビルド実行 (Release, Debug など指定可 ) Build Publisher ｰ ビルド生成物をコピー NAnt Task – NAnt を実行 Executable Task ｰ 実行ファイルを実行 ForceBuildPublisher ｰ 他の CC.NET プロジェクトを実行 NUnit Task ｰ ユニットテスト実行 Email Publisher – mail 送信 タスク各種

26. CC.NET を使った分散ビルド Project Trigger <projectTrigger serverUri=&quot;tcp://server:21234/CruiseManager.rem&quot; project=&quot;Server“/> 他の CC.NET プロジェクトの状態を監視、条件にあえばタスク実行 ForceBuildPublisher <publishers> <forcebuild> <project>AcceptanceTestProject</project> <serverUri>tcp://buildserver2:21234/CruiseManager.rem</serverUri> </forcebuild> </publishers> 他の CC.NET プロジェクトを実行 CC.NET マシンが他の CC.NET マシンを統率または監視してタスクを指示できる。 監視 指示

27. CC.NET からの通知 メール Web CCTray( ローカルアプリケーションに通知 ) ユーザーのタスクトレイにテスト結果通知

28. CruiseControl.NET で できないこと、困ること まっさらな状態からの CVS Chekout 解決案 -> CVS Command を実行する bat で実行 -> NAnt(Build ツール ) と連携 CVS Checkout でロックをかけている ? ローカル各マシンでの commit が遅くなる 解決案 -> CVS の機能を使ってコミット時に連絡用ファイルを作成、連絡用ファイルを監視

29. 常時結合 まずは常時結合から始めるのがオススメです。 リポジトリ監視、変更があればビルド ビルド履歴の保管 UnitTest 定期実行

30. 次に定期テストをやってみましょう。 例えばこんなテストはどうでしょう。

31. テストの基本はお手本との差分 差分比較ツール Fc - Windows 標準コマンドラインツール Diff - Unix, Linux ExamDiff - Windows GUI ツール シェアウェア では、具体的にどんなテストができるか見ていきましょう。 テスト出力結果 正しい出力結果 ソース変更後、意図しない差分がないか調べる

32. 出力比較テスト Output Reference テスト対象 ソースコード 差分比較 Input 以前に出力して問題がないと確信が持てるものを Reference として使用

33. ログ比較テスト ソースコードの要点にログ書き出しを仕込んで置く。 変数 Dump や、 関数の In/Out など。 変数の内容や処理経路が異なる場合に発見できる。 下回りのライブラリが置き換えられた場合も、 自分たちのコード上を通る経路が 変わる場合は違いに気づける。 Output テスト対象 ソースコード Log お手本 Log 差分比較 Input

34. 出力適格判断テスト Output テスト対象 ソースコード 出力が規格に適合しているか調べる 規格 Checker 規格適合性 チェックツールを 入手または作成 結果 Reference 差分比較 Input

35. APIテスト 仮想上位モジュール Output テスト対象 ソースコード Log Reference 差分比較 Input メソッド呼び出し ( 引数 ) 戻り値

36. パフォーマンス測定 パフォーマンスを定期的に測ることで パフォーマンス悪化を早期発見、原因把握 Output テスト対象 ソースコード 出力にかかる時間を測定 グラフ化 -> コード履歴をみれば悪化の原因を絞り込める Input

37. マルチプラットホームテスト 多くのプラットホーム、 OS でのテストも自動なら簡単 こんなことを発見できます。 API の OS Ver. 依存 Windows のホームディレクトリなど OS Ver. 依存の設定 アクセス権依存のコード ( 制限ユーザーで実行など ) 変数 bit 量の違いによる不具合 エンディアネス（リトルエンディアン、ビッグエンディアン）

38. 他のテスト 接続過多テスト バーチャルOSをがんがん起動して一斉に接続 ->できなくはないが、毎日回すテストではないかも。 過負荷テスト ->CPU使用率を狙って上げてテスト これも毎日回すテストではないかも。

39. デイリーテスト事例 デイリーテストカレンダー テスト名 ● NG ● 予告 NG ● AllOK 平穏な日々 不穏な時期 リリース その日の結果

40. 参考文献 http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET – Download site http://confluence.public.thoughtworks.org/display/CCNET/Configuring+the+Server - configuration file reference http:// www.archway.co.jp/tabid/71/Default.aspx - 解説 PDF とパトライト ( 日本語 ) http://tsune.japan.webmatrixhosting.net/NWiki.aspx?page=CruiseControl.NET1.0 – 日本語 wiki 達人プログラマー / デビッド・トーマス著 ISBN:475614599X ( 同名の別書があるので注意 ) Joel on Software / Joel Spolsky 著 ISBN:4274066304

41. キーワード NCover コードのテスト通過率を測定 FxCop コーディング規約チェック 調べる時間がなかったけど、面白そうなものたち

42. 技 リポジトリ変更ドリブントリガー ソースが変更されたか監視するのではなくて、リポジトリにコミットされたタイミングでビルド。リポジトリコミット時のイベントで CC.NET が監視している箇所にダミーファイルを生成することで、 CC.NET の監視する量が激減。 調べる時間がなかったけど、面白そうなものたち

43. NAnt とは何が違うの？ レイヤーが違います。 CC.NET は統合ツール Mail 機能、 web ページ作成機能などがあります。 NAnt はビルドツール CC.NET でも NAnt の豊富な機能を利用してビルドなどの作業を行うことができます。 CC.NET でも簡単なビルド指示は出すことができます。