Next: , Previous: Obsolete Constructs, Up: Top


16 Autotestで一般的なテストスイートを生成する

     
     
     
     
     
     厳重注意:このセクションでは,この次のリリースのAutoconfの一部と
     なっている,実験的な機能を記述しています.我々はAutotestが安定しているこ
     とを信じていますが,このドキュメントでは将来変更される可能性があるインター
     フェースを記述しています.Autoconfのメーリングリストを購読しないまま
     Autotestに依存することはやめてください.

移植性の高いプロジェクトで,テストスイートを実行するために移植性のないツー ルに依存していることは,矛盾しています.Autoconf自身がこの問題の典型です. 2.13までは完全な移植性を目的としていましたが,そのテストスイートは DejaGNUを使用していて,それは高品質で複雑なテストフレームワー クですが,Unixシステムの標準からかけ離れていました.悪いことに,ほとんど の壊れやすいプラットフォームが無いことがよくあり,そのプラットフォームが Autoconfを苦しめ,欠陥を提示していることがほとんどでした.

この問題を回避するために,パッケージ管理者の多くは,その出力が終了ステー タスとなる,つまりテストが成功するまたは失敗するといった,単純なシェルス クリプトをベースに,独自のテストフレームワークを開発してきました.さらに, これらのテストのほとんどは,共通のパターン,重複している大量のコードの結 果,退屈な管理などを共有しています.

以下はAutoconfが生まれた理由と全く同じですが,Autotestは,M4マクロを基本 として移植性の高いシェルスクリプトを構築するテストスイートを生成するフレー ムワークを提供しています.スイート自身は,バグの報告で中断することを限り なく少なくし,自動的なログ生成と追跡機能を備えていて,単純なタイミングで バグは報告されます.

Autoconf自身はAutotestを何年も使用していて,テストスイートとバグの報告の 強さをかなり改善しているattestを実行しています.Autotestの生成物を 使用していることが知られている,Bison,Free Recode,Free Wdiff, GNU Tar といったそれ以外のプロジェクトでは,それぞれ異なるニー ズがあり,一般的なテストフレームワークとしてのAutotestにのんびりと磨きを かけていました.

それにもかかわらず,DejaGNUと比較して,Autotestは対話的なテス トツールとしては不十分で,それがおそらく主な制限事項となっています.