自動 Test とCruiseControl.NET

Kuniaki IGARASHI

2006.8.21

http://igarashikuniaki.net/

目次

各種テストの向き不向き 自動テストのメリット 自動テストツール CruiseConterol.NET 自動テストの始め方 参考文献

目標みなさんが自動テストを始める際の最初の一歩をお手伝い

ところで、

テストを行う理由はなんでしょうか？

不具合を可及的速やかに発見したいから。

（たぶん）

バグ早期発見のメリットゼロ欠陥法 ( 某 M$ 社 )

「いかなる場合でも新しいコードを書く前にバグを取り除くことを最優先とする」

→ バグを発見する手段の 1 つがテストである。

理由 コスト

バグ修正にとりかかるまでの時間が長くなればなるほど、修正にかかるコストは（時間においても金額においても）高くなる

スケジュール見積もりバグが存在している場合、スケジュールの見積もりは非常に困難。既存のバグを修正する時間よりも、新機能を実装する時間の方が遙かに見積もりし易い

テストいろいろ

UnitTest主にメソッド単位のテスト。コード修正が行われるごとに回す。バグ発見までの時間が短い。 定期自動 Test大量のテストデータに関してテストを回す。毎日実行することでバグが入り込んだタイミングがわかる。 人の手によるテスト万能だが、時間と手間がかかる。

テストには様々な種類がある

特徴を理解して適材適所のテストを行うと効果大

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 は必須

UnitTest – テスト駆動開発

メリット テストコードを書くことで仕様が固まる インターフェイスの曖昧さが解消 テストし易いコードを書ける

テスト駆動開発

実装する前にテストを書く

定期自動テスト

定期的にビルドを行い、

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

可 )

常時結合定期的にテストを行うためには、

常時、自動でビルド ( 結合 ) する必要があります。メリット

リポジトリ上ソースのビルド失敗を早期発見CVS add 忘れやソリューション構成変更忘れなどを早期検出可能。他の開発者への影響を最小限で防ぐ　→ リポジトリ上のソースがビルドできない場合、

時差のある 2 拠点開発では最悪丸 1 日仕事不能 バグ発生箇所の追求が容易

ビルドアーカイブを保管することで、過去のある不明な時点で発生したバグを二分検索可能

テスト担当とのスムースな連携テスト担当者が常に最新のビルドを手にいれることができる

定期自動テストのメリット

デイリーテストの実際の成果

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

デイリーテストってばすげー！

ここまでのお話で、

デイリーテストをやってみようかなと、ちょっと思ったり。

デイリーテストを導入したいですか？Yes : これから具体的な方法を説明します。

No : 大人の対応をお願いします。

CruiseControl.NET概要

OpenSource の定期テスト実行ツール(Apache Software License, BSD License)

定期的なビルド、テストが実行可能 Multi Platform 対応

.NET 環境の CruiseControl.NET

JAVA 環境の CruiseControl

CruiseControl.NET(CC.NET) 　常時結合ツールの 1 つ

CruiseControl.NET でできること 定期的なコマンド実行 定期的なソース取得、差分確認 定期的なビルド メール、 web 、アプリケーションで

のビルド結果報告複数マシンでの分散ビルド環境構築

パトライトでエラー時に警告するシステムを構築している人もいます。

CruiseControl.NETを使う 6 つの理由 毎日テストを実行することにより、直前 24 時間

の新規実装で発生したバグを発見できます 別環境でビルドすることで CVS add 忘れなどを

早期発見できます エラー処理やタイムアウトが可能 (bat ファイル

やスクリプトでは途中で処理が止まってしまった場合に後続の処理まで影響を受ける )

複数マシンでの分散ビルドが可能 MulitPlatform 展開する場合に、テストパターン

の書き換えが容易 (Path の書き換え程度 ) テスト OK によって得られる安心感 - Priceless

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

Web でのビルド結果レポート

動作環境

All 32-bit MS Windows (95/98/NT/2000/XP)

Visual Studio .NET CVS Client (CVS を使用する場合 ) IIS (Webレポートを使用する場合 ) SMTP ( メールレポートを使用する場合 )

対応ソース管理システム

VSS, CVS, Subversion 他

インストール - IIS

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

インストール - CC.NET

http://sourceforge.net/projects/ccnet/から Download してインストールしてください。

注意点：Webレポート機能を使う場合は、IIS を先にインストールした方が設定が楽です。

インストール – IIS の設定

管理ツールのインターネットインフォメーションサービスで CC.NET web dashbord が加えられていることを確認してください。

また、 asp.net(aspnet_client) も必要です。入っていない場合は以下のコマンドを実行してインストールしてください。 > %windir%\Microsoft.NET\Framework\v1.1.xxxx\aspnet_regiis.exe -i xxxx にはインストールされたバージョンが入ります。

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

CC.NET設定ファイル

ビルドの指示は以下の xml ファイルに記述します。C:\Program Files\CruiseControl.NET\server\ccnet.config

--- 例 ( 概略 )---<5 分ごとに CVS 監視 >< 変更があれば以下のタスクを実行 > < ソースディレクトリを削除 > <CVS CheckOut> <Build> <Mail 送信 >

Examples フォルダ以下に設定ファイルの例が置いてあります。

CC.NET 設定ファイル

<project name="BuildProject"> <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 エラーを通知

CC.NET設定ファイル

トリガー各種Interval Trigger<intervalTrigger name="continuous" seconds="30" buildCondition="IfModificationExists"/>30 秒ごとにソースリポジトリを監視、変更があればタスク実行

Schedule Trigger<scheduleTrigger time="23:30" buildCondition="ForceBuild“/>決まった時間にタスク実行

Url Trigger<urlTrigger url="http://server/page.html" seconds="30" buildCondition="IfModificationExists"/>

URL で指定したファイルを監視、変更があればタスク実行

Project Trigger<projectTrigger serverUri="tcp://server:21234/CruiseManager.rem" project="Server“/>他の CC.NET プロジェクトの状態を監視、条件にあえばタスク実行

CC.NET設定ファイル

Visual Studio Task ｰ VS でビルド実行 (Release, Debug など指定可 )

Build Publisher ビルド生成物をコピーｰ

NAnt Task – NAnt を実行

Executable Task 実行ファイルを実行ｰ

ForceBuildPublisher 他のｰ CC.NET プロジェクトを実行

NUnit Task ユニットテスト実行ｰ

Email Publisher – mail 送信

タスク各種

CC.NET を使った分散ビルド

Project Trigger<projectTrigger serverUri="tcp://server:21234/CruiseManager.rem" project="Server“/>他の CC.NET プロジェクトの状態を監視、条件にあえばタスク実行

ForceBuildPublisher<publishers>

<forcebuild><project>AcceptanceTestProject</project><serverUri>tcp://buildserver2:21234/CruiseManager.rem</serverUri>

</forcebuild></publishers> 他の CC.NET プロジェクトを実行

CC.NETマシンが他の CC.NETマシンを統率または監視してタスクを指示できる。

監視

指示

CC.NET からの通知

メール

Web

CCTray( ローカルアプリケーションに通知 )

ユーザーのタスクトレイにテスト結果通知

CruiseControl.NET でできないこと、困ること

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

常時結合

まずは常時結合から始めるのがオススメです。

リポジトリ監視、変更があればビルド

ビルド履歴の保管UnitTest 定期実行

次に定期テストをやってみましょう。

例えばこんなテストはどうでしょう。

テストの基本はお手本との差分

テスト出力結果 正しい出力結果

ソース変更後、意図しない差分がないか調べる

では、具体的にどんなテストができるか見ていきましょう。

差分比較ツール Fc - Windows 標準コマンドラインツール Diff - Unix, Linux

ExamDiff - Windows GUI ツール シェアウェア

出力比較テスト

Output Reference

テスト対象

ソースコード

差分比較

Input

以前に出力して問題がないと確信が持てるものを Reference として使用

ログ比較テストソースコードの要点にログ書き出しを仕込んで置く。変数 Dump や、関数の In/Out など。変数の内容や処理経路が異なる場合に発見できる。

下回りのライブラリが置き換えられた場合も、自分たちのコード上を通る経路が変わる場合は違いに気づける。

Output

テスト対象

ソースコード

Log

お手本

Log

差分比較

Input

出力適格判断テスト

Output

テスト対象

ソースコード

出力が規格に適合しているか調べる

規格 Checker

規格適合性

チェックツールを

入手または作成

結果

Reference

差分比較

Input

仮想上位モジュール

API テスト

Output

テスト対象

ソースコード

メソッド呼び出し(引数 )

戻り値

LogReference

差分比較

Input

パフォーマンス測定パフォーマンスを定期的に測ることでパフォーマンス悪化を早期発見、原因把握

Output

テスト対象

ソースコード 出力にかか

る時間を測定

グラフ化

→ コード履歴をみれば悪化の原因を絞り込める

Input

マルチプラットホームテスト

多くのプラットホーム、 OS でのテストも自動なら簡単

こんなことを発見できます。 API の OS Ver.依存 Windows のホームディレクトリなど OS Ver.依存の設

定 アクセス権依存のコード (制限ユーザーで実行など ) 変数 bit 量の違いによる不具合 エンディアネス（リトルエンディアン、ビッグエンディ

アン）

他のテスト

接続過多テストバーチャル OS をがんがん起動して一斉に接続→ できなくはないが、毎日回すテストではない

かも。

過負荷テスト→CPU使用率を狙って上げてテストこれも毎日回すテストではないかも。

デイリーテスト事例デイリーテストカレンダー

テスト名

●NG

●予告 NG

●AllOK

平穏な日々 不穏な時期リリース

その日の結果

参考文献 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

キーワード

NCover

コードのテスト通過率を測定FxCop

コーディング規約チェック

調べる時間がなかったけど、面白そうなものたち

技

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

調べる時間がなかったけど、面白そうなものたち

NAnt とは何が違うの？

レイヤーが違います。

CC.NET は統合ツール

Mail機能、 webページ作成機能などがあります。

NAnt はビルドツール

CC.NET でも NAnt の豊富な機能を利用してビルドなどの作業を行うことができます。 CC.NETでも簡単なビルド指示は出すことができます。