[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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) |
このテストスクリプトは、バッチ処理でもインタラクティブセッションからでも 実行できます。インタラクティブセッションの場合はこのテストスクリプトを ただロードすれば、各テストの結果とサマリーが報告されます。 バッチテストの場合は、標準出力を別のファイルにリダイレクトしておくと良いでしょう。 標準出力が端末でない場合、テスト手続きは詳しい結果をstdoutに出力し、簡単な メッセージを標準エラー出力に書き出します。
モジュールやプログラムを書いたら、Makefileに"test"ターゲットを作ることを お薦めします。ルールはこんな感じになるでしょう:
test : gosh my-feature-test.scm > test.log |
thunkを呼び、その結果をexpectedと比較します。
比較手続きには、引数compareが与えられていればそれを用い、
そうでなければequal?
を用います。nameはログに残すためのテストの名前です。
thunk内で捕捉されないエラーが発生した場合、それは捕捉され、
特別なエラーオブジェクトに置き換えられます。グローバル変数*test-error*
がエラーオブジェクトに束縛されており、エラーが期待される状況もテストすることが
できます。
手続きcompareは次のように呼び出されます。
(compare expected result-of-thunk) |
この手続きは、渡された結果が期待する値と合致する場合に#t
を、
そうでなければ#f
を返さなければなりません。
特別な比較手続きのひとつの用法は、不正確な数値を、多少の誤差を許して
比較するような場合です。
(test "test 1" (/ 3.141592653589 4) (lambda () (atan 1)) (lambda (expected result) (< (abs (- expected result)) 1.0e-10))) |
特別なエラーオブジェクトに束縛されています。 テストのthunkがエラーを起こすことが期待されている状況で、 エラーオブジェクトをexpected引数に渡すことができます。
(test "test if car signals an error" *test-error* (lambda () (car 5))) |
この変数が真であれば、test
ルーチンはエラーを捕捉した際に
スタックトレースをカレントエラーポートに出力します。
期待しない状況でtest-errorオブジェクトが返された際に、そのエラーが
どこで起こったかを知るのに役立つでしょう。
この変数はgauche.test
モジュールが読み込まれた時点で
環境変数GAUCHE_TEST_REPORT_ERROR
の値により初期化されます。
例えば、テストスクリプト中の予期せぬエラーを調べるのに、
次のようにすることができるでしょう (環境変数がセットされていれば、値は関係ありません)。
env GAUCHE_TEST_REPORT_ERROR=1 gosh mytest.scm |
exprをlambdaでくるんでくれる便利なマクロです。
(test* name expected expr) ≡ (test name expected (lambda () expr)) |
Moduleはモジュール名のシンボルかモジュールでなければなりません。 この手続きはモジュールmoduleに関していくつかの経験的な一貫性チェックを 行います:(1) autoloadに設定されたシンボルがちゃんとロードできるか、 (2) exportにリストされたシンボルがモジュール内で定義されているか、 (3) 関数中で参照されているグローバル変数が全て定義されたものであるか。 この手続きは完璧ではないものの、 ケアレスミスによる名前の綴り間違いを発見することができます。
しばしば、プラットフォームやコンパイルオプションによって
グローバル変数が定義されるかどうかが異なる場合があります。
コード中では実行時にその変数の存在を確認してから使うように
コーディングしてあったとしても、test-module
は
そのようなロジックを追わないため、未定義変数の参照を報告して
しまいます。そのような場合は、チェックから外す変数名のリストを
allow-undefinedキーワード引数に渡して下さい。
テストの状態を初期化して、ヘッダをログに書き出します。テストを呼ぶ前に呼んで下さい。 module-nameはログのために使われる文字列です。
一群のテストの開始をマークします。単にログに使われるだけです。
失敗したテストのリストを報告し、その総数を返します。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Shiro Kawai on October, 7 2008 using texi2html 1.78.