試験の中には必然的に環境に依存した結果となるものがありますので、「expected」結果ファイルの代替を指定する方法を用意しています。 各リグレッションテストは、異なるプラットフォームで出力される可能性がある、複数の比較用ファイルを持つことができます。 各試験に対してどの比較用ファイルを使用するかを決定する方法には、独立した2つの機構があります。
1つ目のメカニズムにより、特定のプラットフォームのための比較用ファイルを選ぶことができます。
関連付けを行うsrc/test/regress/resultmap
というファイルがあり、どの比較用ファイルがどのプラットフォームで使用されるのかを定義します。
特定のプラットフォームにおいて試験の「失敗」の誤検知を防ぐためには、まず結果ファイルを選ぶ、あるいは結果ファイルを作成してから、resultmap
ファイルに1行加えてください。
マッピングファイルの各行の書式は下記の通りです。
testname:output:platformpattern=comparisonfilename
testnameは特定のリグレッションテストのモジュール名です。
outputの値は、どの出力ファイルを検査するのかを示します。
標準のリグレッションテストでは、これは常にout
です。
この値は出力ファイルの拡張子に対応します。
platformpatternとは、expr
Unixツールスタイル(最初に暗黙的な^
がある正規表現)のパターンです。
これはconfig.guess
によって出力されるプラットフォーム名と比較されます。
comparisonfilenameは置き換える結果比較ファイルの(ディレクトリ部分を除いた)名前です。
以下に例を示します。
システムの中には、動作するstrtof
関数がないものがあり、そのため私たちの回避策がfloat4
リグレッションテストでの丸め誤差の原因となります。
そのため、float4-misrounded-input.out
という異なる比較ファイルを用意し、そこにこういったシステムでの期待される値を記述します。
HP-UX 10プラットフォームにおいて偽の「失敗」メッセージ出力を行わせないようにするために、resultmap
に以下を含めます。
float4:out:hppa.*-hp-hpux10.*=float4-misrounded-input.out
これは、config.guess
の出力がhppa.*-hp-hpux10.*
に一致するすべてのマシンに対して適用されます。
resultmap
のその他の行は、他のプラットフォーム向けの適切な比較ファイルを選択します。
2つ目の比較用ファイルの選択の仕組みはかなり自動化されています。
これは単純に、提供されている各種比較用ファイルの中から「もっとも一致するもの」を使用します。
リグレッションテストのドライバスクリプトは、試験において、標準の比較用ファイル
とtestname
.out
(ここでtestname
_digit
.outdigit
は0
-9
のいずれかからなる1つの数字です)という名前の別のファイルの両方を考慮します。
もしこの中のいずれかのファイルが正確に一致した場合、試験が成功したものとみなします。
さもなくば、生成されたdiffの結果がもっとも小さかった結果ファイルを選択して、失敗報告を生成します。
(resultmap
に特定の試験用の項目が含まれていると、resultmap
内の名前が元となるtestname
に置き換えられます。)
例えば、char
の試験では、比較用ファイルchar.out
にはC
ロケールとPOSIX
ロケールで想定される結果が含まれています。
一方、char_1.out
ファイルには、他の多くのロケールで現れる結果がソートされて含まれています。
この最善一致の仕組みは、ロケールに依存した結果に対応できるように考え出されました。 しかし、この仕組みはプラットフォームの名前だけでは簡単に予測できる試験結果とならないような、任意の状況で使用することができます。 この仕組みの制約は、現在の環境でどの種類の比較ファイルが本当に「正しい」のかが試験ドライバでは分からないという点です。 単にもっともうまく動いていそうなものを選択しているだけだからです。 したがって、すべての文脈で平等に有効とみなすことができるような種類の結果においてのみ利用するのが、もっとも安全です。