![]() |
![]() |
![]() |
Cutterリファレンスマニュアル | ![]() |
---|
Cutterは以下のような単体テストフレームワークの基本的な機能を 持っています。
フィクスチャ
テスト登録コード不要
デバッグに便利な結果出力
豊富な検証機能
Cutterは以下のようなテスト環境をもっと便利にする高度な機能も あります。
複数のプラットフォーム対応
データ駆動テストのサポート
カバレッジのサポート
クラッシュ時のバックトレース出力
テスト結果の保存・復元
...
単体テストフレームワークが一般的に提供している機能について、 Cutterがどのようにその機能を提供しているかについてを説明しま す。
単体テストフレームワークでいうフィクスチャとは、各テストを実 行する前にテスト用データを用意するための仕組みのことです。こ れは、一般的には各テスト毎にsetup/teardownと呼ばれる初期化処 理/終了処理を実行することによって実現します。
Cutterでは以下のようにテストプログラム中にsetup()/teardown() 関数を定義すると、それらの関数が初期化処理/終了処理として扱 われます。
void setup (void) { /* 初期化処理 */ } void teardown (void) { /* 終了処理 */ }
また、Cutterではテストケース毎の初期化処理/終了処理のために startup()/shutdown()もサポートしてます。
void startup (void) { /* テストケースの初期化処理 */ } void shutdown (void) { /* テストケースの終了処理 */ }
これらの関数は以下のような順番で呼ばれます。
startup()
setup()
テスト1実行
teardown()
setup()
テスト2実行
teardown()
...
shutdown()
また、実験的な機能ですが、テスト全体を実行する前、テスト全体 を実行した後に呼び出す関数を登録することもできます。これらの 関数をそれぞれwarmup/cooldownと呼んでいます。呼び出し順序は こうなります。
warmup実行
テストケース1のstartup()
テストケース1のsetup()
テスト1-1実行
テストケース1のteardown()
テストケース1のsetup()
テスト1-2実行
テストケース1のteardown()
...
テストケース1のshutdown()
テストケース2のstartup()
テストケース2のsetup()
テスト2-1実行
テストケース2のteardown()
テストケース2のsetup()
テスト2-2実行
テストケース2のteardown()
...
テストケース2のshutdown()
...
cooldown実行
この機能は、テスト対象のライブラリがライブラリ初期化関数・終 了関数を用意している場合に有用です。ただ、この機能は実験的な 機能なのでここでその使い方を紹介するのは控えておきます。もし、 使いたい場合は聞いてください。
動的な言語用の単体テストフレームワークの多くでは明示的にテス トを登録する必要はありません。自動的にテストメソッド・テスト 関数などを見つけて実行します。しかし、C言語用の単体テストフレー ムワークの多くでは明示的にテストを登録する必要があります。
Cutterはテストを簡単に書けるようにするため、多くの動的な言語 用の単体テストフレームワークのように自動的にテスト関数を見つ けます。そのため、以下のように名前が「test_」からはじまる公開 関数を定義するだけでその関数がテスト関数として認識されます。
void test_my_function (void); void test_my_function (void) { /* テスト関数 */ }
Cuterは迅速に問題の確認・修正が行えるようにテスト結果を出力し ます。具体的には以下のように出力を行います。
問題がない部分はシンプルに
問題がある部分は冗長に
まず、問題がない部分をシンプルに表示する(時には何も表示しな い)ことにより大事な情報が埋もれてしまうことを防ぎます。
また、問題がある部分はどのような問題があるかを判断するために、 知っている情報をできるだけ多く表示します。
例えば、文字列が同じ内容かを比較するテストで文字列が異なって 場合を考えます。Cutterは期待値と実測値を並べて表示します。こ れによりどの部分が異なるかを目視で確認しやすくなります。
expected: <abc def ghi jkl> but was: <abc DEF ghi jkl>
もし、これがずれて表示されていたり、同じ行に表示されていると どこが異なるかを見つけるのは大変になります。
expected: <abc def ghi jkl> but was: <abc DEF ghi jkl> <abc def ghi jkl> is expected but was <abc DEF ghi jkl>
また、必要ならば期待値と実測値のdiffを表示して具体的にどこが 異なるのかも示します。
expected: <abc def ghi jkl> but was: <abc DEF ghi jkl> diff: - abc def ghi jkl ? ^^^ + abc DEF ghi jkl ? ^^^
このように、Cutterにはテストが失敗した時に迅速に問題を確認す るための工夫が施されています。これにより、開発者が迅速に問題 を修正することを支援します。
xUnit系の単体テストフレームワークではテスト対象が期待する動 作をしているかを検証するために、assertionと呼ばれる検証機能 を提供します。例えば、一般的には以下のような検証機能がありま す。
assert: 検証対象が真の値であることを検証
assert_equal: 実測値が期待値と等しいことを検証
Cutterでは、以下の検証機能が上記の検証機能に対応します。
cut_assert()
cut_assert_true(): 機能はcut_assert()と同じだが「真の値」 であることを明示(自己記述的なためこちらの利用を推奨)
cut_assert_equal_int()
cut_assert_equal_uint()
cut_assert_equal_string()
...
Cutterは上記のような一般的な検証機能以外にも様々な検証機能が 組み込みで提供しているので、より簡単にテストを書くことができ ます。例えば、以下のような検証機能を提供しています。
cut_assert_errno(): errnoが0であることを検証
cut_assert_match(): 実測値の文字列が指定した正規表現にマッ チすることを検証
cut_assert_path_exist(): 指定したパスが存在することを検 証
...
検証機能の一覧はリファレンスマニュアルの 検証 や GLibサポート付きの検証 を見てください。
一部の単体テストフレームワークが提供している機能のCutterでの 提供の仕方、および、どの単体テストフレームワークも提供してい ないCutter独特の機能について提供について説明します。
複数のデータに対して同じテストを実行する場合があります。例え ば、以下のような場合が考えられます。
複数の入力パターンがあり、それらを網羅的にテストする場合
複数のバックエンドを抽象化し、どのバックエンドを利用して いる場合でも同じインターフェイスで扱えるライブラリをテス トする場合。(cairoやDBIなど)
このような場合、テスト自体は1つだけ定義し、各テストデータに 対してそのテストを実行することで効率的にテストを作成すること ができます。このようなテストの仕方はデータ駆動テストと呼ばれ ています。
Cutterでのデータ駆動テストの書き方については cut_add_data() を見てください。
データ駆動テストの場合はテストは以下のような流れで実行されま す。
テストデータ生成関数呼び出し
setup()
テストデータ1を使ってテスト実行
teardown()
setup()
テストデータ2を使ってテスト実行
teardown()
...
カバレッジ率はどの程度テストを網羅的に行っているかを示す指標 になります。
CutterはGCCを使用したカバレッジ測定を支援するためのM4マクロを 提供しています。GNU Autoconf/GNU Automakeを利用している場合は このM4マクロを利用することにより、カバレッジ測定環境を簡単に ビルドシステムに組み込むことができます。
詳しくは README や チュートリアル の AC_CHECK_COVERAGEについて書かれている部分を見てください。
C言語で実装されたプログラムではSegmentation Faultでプログラム が異常終了することは珍しくありません。この時、CutterはSEGV シ グナルが発生した時点でのバックトレースの取得を試みます。取得 できた場合はバックトレースを出力してから終了します。もちろん、 この時点でテストプロセスがなにかしら破壊されているので、必ず しもバックトレースを取得できるわけではありません。
問題の詳細を調べるには、GDBなどのデバッガで処理を追いかけて いく必要がありますが、バックトレースをデバッグの最初の足がか りとして利用することができます。
ソフトウェアの品質を確認する方法として以下のような方法があり ます。
テスト状況とバグ発見数の推移を測定
テスト状況とバグ報告数の推移を測定
テスト状況とソース規模の推移を測定
例えば、テストが増えているのにバグ発見数が少ない場合は、効率 の悪いテストを行っている、あるいはもともとテスト対象の品質が 高かったということが考えられます。テストが増えているのにバグ 報告数が伸びている場合は的外れなテストを行っているかもしれま せん。ソース規模が大きくなっているのにテストが増えていない場 合はテスト不足が考えられます。
このように、その時点でのテスト状況だけではなく、過去のテスト 結果も利用して時系列でソフトウェアの開発状況を分析することに より、ソフトウェアの品質向上に役立てることができる場合があり ます。
Cutterはテスト結果をXMLとしてファイルに保存することができます。 また、保存したXMLを読み込んでテスト結果を復元することができま す。
まだ実装されていませんが、保存したテスト結果を読み込んで、時 系列のグラフとしてレポートを出力する機能の実装を予定していま す。