For Gauche 0.9.5


Next: , Previous: , Up: ライブラリモジュール - Gauche拡張モジュール   [Contents][Index]

9.31 gauche.test - 単体テスト

Module: gauche.test

テストスクリプトを書くための手続きを提供します。 テストスクリプトは次のような形になります。

(use gauche.test)
(test-start "my feature")
(load "my-feature")  ; テストすべきプログラムをロード
(import my-feature)  ; モジュールを定義している場合はインポート

(test-module 'my-feature) ; モジュールの一貫性チェック

(test-section "feature group 1")
(test "feature 1-1" EXPECT (lambda () TEST-BODY))
(test "feature 1-2" EXPECT (lambda () TEST-BODY))
 …

(test-section "feature group 2")
(define test-data ...)
(test "feature 2-1" EXPECT (lambda () TEST-BODY))
(test "feature 2-2" (test-error) (lambda () TEST-THAT-SIGNALS-ERROR))
 …

(test-end :exit-on-failure #t)

このテストスクリプトは、バッチ処理でもインタラクティブセッションからでも 実行できます。インタラクティブセッションの場合はこのテストスクリプトを ただロードすれば、各テストの結果とサマリーが報告されます。 バッチテストの場合は、標準出力を別のファイルにリダイレクトしておくと良いでしょう。 標準出力が端末でない場合、テスト手続きは詳しい結果をstdoutに出力し、簡単な メッセージを標準エラー出力に書き出します。

モジュールやプログラムを書いたら、Makefileに"check"ターゲットを作ることを お薦めします。ルールはこんな感じになるでしょう:

check :
        gosh my-feature-test.scm > test.log

テストファイルの構造

Function: test-start module-name

テストの状態を初期化して、ヘッダをログに書き出します。テストを呼ぶ前に呼んで下さい。 module-nameはログのために使われる文字列です。

Function: test-section section-name

一群のテストの開始をマークします。単にログに使われるだけです。

Function: test-log fmtstr args …

この手続きも単なるログのためのものです。 formatと同じようにfmtstrargsからフォーマット済み文字列を 作り、;; を前に、改行文字を後につけて現在の出力ポートへと出力します。

典型的なMakefileでのテスト起動では、テストスクリプトの標準出力をログに流すので、 このメッセージもログにのみ記録されることになります。

この手続きは、自動化テストで検査することは出来ないけれどトラブルシューティングに 役に立つかもしれない情報をダンプしておくのに使えます。 例えば、謎のテスト失敗報告が来て、でも手元ではどうしても再現できず、 実行システムに固有のある側面が影響しているのではないかと推測できたとしましょう。 その場合、test-logでそういった情報をダンプするコードをテストスクリプトに 仕込んでおいて、もう一度報告者のマシンでテストを走らせてもらい、そのログを解析する ことができるでしょう。

Function: test-end :key exit-on-failure

失敗したテストのリストを報告します。exit-on-failure#fか 省略された場合は、この手続きは失敗したテストの数を返します。

そうでなければ、この手続きはexitを呼んでgoshを 終了させます。exit-on-failureにfixnumが渡された場合は、 それがプロセスの終了ステータスとして使われます。exit-on-failureが 他の真となる値であった場合は、終了ステータスは1となります。

Function: test-record-file file

テストスクリプトがいくつかある場合を考えます。通常は、それらのテストスクリプト をひとつづつ走らせて結果を確かめるのではなく、全部を一気に走らせて 簡単な結果のまとめだけを知りたいと思うでしょう。

test record fileはテスト結果を集積するための補助ファイルです。 その内容は次のような一行のサマリになっています。

Total:  9939 tests,  9939 passed,     0 failed,     0 aborted.

test record fileが既に存在していると、test-startは それを読みこんで数字を覚えておきます。そしてtest-endが そのスクリプト中のテスト結果の数字を加算して、同じtest record fileに書き戻します。

makefileのcheckターゲットを次のように書いておけば、 make checkを実行するたびにテスト結果の一行サマリを 得ることができます。 ただし、test1.scmtest2.scmtest3.scmはいずれも test-start呼び出し前に(test-record-file "test.record")を 評価しているものとします。

check:
        @rm -f test.record test.log
        gosh test1.scm >> test.log
        gosh test2.scm >> test.log
        gosh test3.scm >> test.log
        @cat test.record

test-record-file手続きがうまく動作するためには、それが test-startより前に呼ばれなければならないことに注意してください。

この手続きのかわりに、環境変数GAUCHE_TEST_RECORD_FILEを使って test record fileを指定することもできます。

Environment Variable: GAUCHE_TEST_RECORD_FILE

テストスクリプトが走る時にこの環境変数が指定されていれば、 その値がtest record fileの名前として使われます。

ただしテストスクリプト中にtest-record-fileの呼び出しがあると そちらが優先され、この環境変数は無視されます。

Function: test-summary-check

テストレコードファイルが(test-record-fileもしくは環境変数 GAUCHE_TEST_RECORD_FILEによって)設定されていた場合、 それを読み込んで、失敗カウントとアボートカウントがともに0でなければ 終了ステータス1でexitします。テストレコードファイルが設定されていなければ 何もしません。

これは、複数のテストスクリプトを持っていて、どれかが失敗したらmakeに それを伝えたいけれども、テストスクリプト自体はすべて走らせたい、という場合に便利です。 各テストスクリプトでtest-end:exit-on-failureを 使ってしまうと、makeは失敗したテストスクリプトのところで処理を打ち切って しまいます。そこで:exit-on-failureを使うのを避け、 テストレコードファイルを使い、ビルドの最後にこの関数を呼ぶようにします:

check:
   rm -f $GAUCHE_TEST_RECORD_FILE test.log
   gosh test1.scm >> test.log
   gosh test2.scm >> test.log
   cat $GAUCHE_TEST_RECORD_FILE /dev/null
   gosh -ugauche.test -Etest-summary-check -Eexit

こうしておくとmakeは失敗があろうともすべてのテストスクリプトを 実行し (goshは常に終了ステータス0で終了するので)、 最後の行でテストレコードファイルを参照して、失敗があった場合に makeにそれを伝えることができます。

個々のテスト

Macro: test* name expected expr :optional check

exprをlambdaでくるんでくれる便利なマクロです。

(test* name expected expr)
  ≡ (test name expected (lambda () expr))
Function: test name expected thunk :optional check

thunkを呼び、その結果がexpectedに沿っているかを checkを次のとおり呼び出すことで確認します。

(check expected result-of-thunk)

この手続きは、渡された結果が期待する値と合致する場合に#tを、 そうでなければ#fを返さなければなりません。 デフォルトのcheck手続きは下で述べるtest-checkです。 これは、expectedがいくつかの特殊なテストオブジェクトである場合をのぞき、 expectedresult-of-thunkequal? である場合に#tを返します。すなわち、通常はテスト式の結果が 期待するものとequal?であればテストは成功である、ということです。 (特別な場合については下の “曖昧な結果をテストする” および “異常系をテストする” の項を見てください)。

特別な比較手続きのひとつの用法は、不正確な数値を、多少の誤差を許して 比較するような場合です。

(test "test 1" (/ 3.141592653589 4)
      (lambda () (atan 1))
      (lambda (expected result)
        (< (abs (- expected result)) 1.0e-10)))

nameはログに残すためのテストの名前です。

thunk内で捕捉されないエラーが発生した場合、それは捕捉され、 特別なエラーオブジェクト<test-error>に置き換えられます。 その結果を、下で説明するtest-error手続きで作った<test-error> オブジェクトと比較することにより、エラーが期待されたものであるか、 また適切な例外が上がっているかをテストすることができます。

Function: test-check expected result :optional fallback

テスト式の結果が期待された値に合致していることをチェックするために testtest*が使うデフォルトの手続きです。 基本的に、test-checkexpectedresultfallbackに渡された手続きで比較するだけです。fallbackの デフォルト値はequal?です。 ただし、以下に述べるとおり、expectedが特殊なテストオブジェクト だった場合には特別な振る舞いをします。

曖昧な結果をテストする

Function: test-one-of choice …

時々、テスト式exprの結果が外部の環境に左右されるため、 ひとつの確定した値を期待値expectedとして書いておけない場合があります。 この手続きはそのようなテストを簡単に書けるようにします。

choice … のいずれか を表現する特別なオブジェクトを返します。 デフォルトの検査手続きであるtest-checkは、expected引数に そのオブジェクトが渡ってきた場合には、テスト結果とchoice …を ひとつづつ照合し、どれかがマッチすれば真を返します。

例えば次のテストは、procが1か2を返せば成功となります。

(test* "proc returns either 1 or 2" (test-one-of 1 2) (proc))
Function: test-none-of choice …

choice … のいずれでもない を表現する特別なオブジェクトを返します。 テストは、テスト結果がchoiceのどれにもマッチしなかった時に成功となります。

異常系をテストする

Function: test-error :optional (condition-type <error>)

与えられたcondition-typeと適合する<test-error>オブジェクト とマッチするような、新たな<test-error>オブジェクトを作成して返します。

テスト結果をチェックするtest-check手続きは<test-error>オブジェクトを 特別に扱います。err-expectederr-actualが ともに<test-error>のインスタンスであるとき、 (test-check err-expected err-actual)err-expectedの持つcondition typeがerr-actualの それと同じであるか、スーパータイプである場合に#tを返します。

例えばfooの呼び出しが<io-error> (もしくはそのサブタイプ) の コンディションを投げるかどうかをテストしたければ、次のように書くことができます。

(test "see if foo raises <io-error>" (test-error <io-error>) (foo))
Variable: *test-error*

(非推奨) condition typeとして<error>を持つ<test-error> オブジェクトに束縛されています。この変数は互換性のためにのみ残されています。 新しいコードは上に述べたtest-error手続きを使ってください。

Variable: *test-report-error*

この変数が真であれば、testルーチンはエラーを捕捉した際に スタックトレースをカレントエラーポートに出力します。 期待しない状況でtest-errorオブジェクトが返された際に、そのエラーが どこで起こったかを知るのに役立つでしょう。

この変数はgauche.testモジュールが読み込まれた時点で 環境変数GAUCHE_TEST_REPORT_ERRORの値により初期化されます。 例えば、テストスクリプト中の予期せぬエラーを調べるのに、 次のようにすることができるでしょう (環境変数がセットされていれば、値は関係ありません)。

env GAUCHE_TEST_REPORT_ERROR=1 gosh mytest.scm

準静的検査

Schemeは動的型付けで、これはREPLでインクリメンタルあるいは実験的な開発を するには便利なのですが、コードが実際に走るまでエラーに気づかないということになりがちです。 しばらく走らせた後で変数名のタイポで止まってしまうと腹立ちますよね。

Gaucheでは、こういった種類のエラーをテスト時に検査する方法を用意しています。 これは完全に静的な検査ではありません(対象のモジュールやスクリプトをロードするので、 トップレベル式は実行されてしまいます)し、網羅的でもありません (複数のモジュールを見たり、実行時に追加される情報に依存するものは検査できません)。 それでも、変数名の間違いや引数の個数の誤りなどよくあるミスはこの検査で大抵見つけることが できます。

test-moduletest-script手続きはそれぞれ、 指定されたモジュールもしくはスクリプトをロードし (その過程でSchemeコードは VM命令列へとコンパイルされます)、次にコンパイルされたVMコードを走査して 以下のテストを行います。

  1. 関数内から参照されているグローバル変数は(該当モジュール内、もしくはインポートしたモジュールで) 全て定義されているか
  2. グローバル変数が関数として使われているなら、その引数の数が 関数の定義と合致しているか。
  3. autoloadに設定されている変数が実際にロードできるか。
  4. モジュールをテストしている場合、exportされているシンボルが 定義されているか。

今のところ検査はヒューリスティックで、エラーを見逃すこともあれば、 エラーでないものをエラーと報告してしまう可能性もあります。後者については、 偽陽性となるシンボルを列挙して検査から外すようにできます。

Function: test-module module :key allow-undefined bypass-arity-check

モジュールをロードし、準静的な一貫性チェックを行います。 Moduleはモジュール名のシンボルかモジュールでなければなりません。

しばしば、プラットフォームやコンパイルオプションによって グローバル変数が定義されるかどうかが異なる場合があります。 コード中では実行時にその変数の存在を確認してから使うように コーディングしてあったとしても、test-moduleは そのようなロジックを追わないため、未定義変数の参照を報告して しまいます。そのような場合は、チェックから外す変数名のリストを allow-undefinedキーワード引数に渡して下さい。

引数の個数のチェックも、偽陽性のエラーをあげる可能性があります。 モジュールがロードされた後のグローバルな関数の変更を当てにしている場合などです (例えば、コード中であるジェネリックファンクションに渡されている引数の個数が、 モジュールのロード時点では不正なものだったとしても、そのコードが実行される までに該当引数のメソッドが追加されれば、正しいコードとなるわけです)。 自分のコードは確かに正しく、チェックが誤りであるような場合は、 該当関数の名前のリストをbypass-arity-checkキーワード引数に 渡してください。

Function: test-script filename :key allow-undefined bypass-arity-check

filenameで指定されるスクリプトを新しい無名モジュールにロードし、 準静的な一貫性チェックを行います。 filenameはスクリプトファイル名を指定する文字列でなければなりません。

キーワード引数の意味はtest-moduleと同じです。

filename中のトップレベルフォームは評価されるので、 トップレベルフォームのアクションに依存したスクリプトは望ましくない副作用を生じるでしょう。 この検査は、スクリプトがsrfi-22形式、 つまりアクションをmain手続きから呼ぶようになっているとうまくいきます。 R7RSスクリプトはトップレベルフォームのアクションに頼らざるを得ないので この手続きではうまく検査できません。

スクリプトがuserモジュールにロードされることに依存して書かれている場合も、 この手続きではうまくいきません。


Next: , Previous: , Up: ライブラリモジュール - Gauche拡張モジュール   [Contents][Index]