初めての reftest
reftest ハーネスは 2 つの視覚構造 (visual constructs)を比較するものとして考えることができます。2つのファイルから作られる視覚構造が完全に同一の場合、そのテストは通ります。異なる場合、テストは失敗します。そのツールの力は与えられた視覚効果をブラウザで実現する方法は一つ以上あるという事実からきています。そこで、複雑なマークアップの効果がテストされる場合、複雑なマークアップをあるページに埋め込み、同じ視覚効果を実現する単純なマークアップを使うもう一つのページを作ってください。reftest はそれらを比較し、同じ視覚構造を実現したかを確認します。
この考えは最初にであったとき奇妙に見えるかもしれません。自動テストは通常、正しいと認識されている不変条件 (invariant)、「gold standard」("Wikitionary によると gold standard は「究極、または理想的であると考えられるかテストか比較基準」とのこと")と出力を比較します。もし、ある人が数字のかけ算を行うソフトウェアを持っていた場合、その人は 2×2が 4 に近いなにかではなく、正確に 4 であることを示すリグレッションテストを望みます。しかしオペレーティングシステムは時と共に変化します。これは不変条件ではありません。さらにブラウザも、関連した標準への準拠を進める間に、ある要素の視覚効果を変更するでしょう。例えば、W3C の HTML 4.01 仕様は "<blockquote>" の内側のテキストがインデントされるだろうことを規定していますが、インデントのピクセル数は規定していません。もしブラウザがインデントの深さを変更し、視覚構造が不変条件とテストされると、テストに落ちるでしょう。しかし <blockquote> 要素がインデントを一切しなくならない限り、テストに落ちるべきではないのです。もしリグレッションテストハーネスがを持っているなら、そのハーネスは信頼できなくなり、使われなくなるでしょう。
例がこれを明らかにするでしょう。これはばかばかしい例ですが、最初の reftest を作りの歩を進めてくれるでしょう。
- 手順 1
-
テストを実行するためにブラウザをチェックアウトしビルドする必要があります。これを行う詳細はBuild Documentationを参照してください。ごめんなさい、しかしリリースされたビルドと nightly ビルドは "
--disable-tests" オプション付きでビルドされ、reftest は動かないでしょう (バグ 369809 を参照)。 - 手順 2
- ターミナルウィンドウを開くディレクトリを作り、そのディレクトリをカレントディレクトリにします (つまり作成したディレクトリに移動します)。
- 手順 3
-
以下の内容で
foo.htmlというファイルを作成します。
<html><head><title>reftest0001</title> <body><strong>Hello!</strong></body> </html>
- 手順 4
-
以下の内容で
bar.htmlというファイルを作成します。
<html><head><title>reftest0001</title> <body><b>Hello!</b></body> </html>
- 手順5
-
以下の内容で
reftest.listというファイルを作ります。
== foo.html bar.html
現時点でテストを実行する準備ができています。私がテストを実行する方法です。あなた自身のプラットフォームに合わせてください。
% /bin/sh $ /Users/ray/mo/browser/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox -P minefield1 -reftest ./reftest.list 2>&1 | grep REFTEST REFTEST PASS: file:///Users/ray/moz/reftest0001.html $
おめでとうございます!あなたはちょうど最初の reftest を作成したところです!
上のブラウザの起動で、"-P minefield1" はテストのために設定したプロファイルを確実に使わせています。このプロファイルに個人的なデータや重要なデータを入れるべきではありません。(プロファイルの設定に関する詳細は Firefox Help を参照してください。) リダイレクトと grep はブラウザからの大量の出力を減らします。もしブラウザのデバッグバージョンをビルドしたなら、追加のコンソール出力が大量にありえます。reftest.list は好きなように名前を付けることができます、reftest.list である必要はありません。
さらにやること
さらに reftest を作りましょう。新しいテストは reftest.list に追加できます。reftest.list にはいくらでもテストを含めることができます。そのファイルには他のことも含めることができますが、とても複雑にはなりません。例があります include ../other.list
== foo.html bar.html != aaa.html bbb.html
最初の行は、予想した人もいるでしょうが、他のマニフェストを読み込みます 二行目見たことがあるはずです。これは foo.html と bar.html が視覚的に完全に同じ出力を生成するべきことを表しています。三行目は aaa.html と bbb.html が視覚的に完全に同じではない出力を生成するべきことを表しています。このファイルは下で参照されている README.txt で見つけることができます。そのファイルは reftest ツールの作者によって書かれました。
自動テスト関して明白ではないかもしれない一つの事があります。小さ過ぎるテストを構成する方法が本当に全くありません。あなたが何かを確認したいと思い、それが些細なことに思えるのであれば、それは間違いありません。自動テストスイートに新しいテストを追加するコストは非常に低いです。手動で実行されるテストでは、こっれは真実ではありません。手動テストを考え、管理し実行するコストはとても高いです。これは手動のテストがより長くなり、より多くのステップを含み、結局実際に多くのものをテストする長い一覧表になる傾向の理由です。
つまり小さなテストを作ってください。例えば、要素の名前と属性名の間の空間は効き目がないと見なしていますが、私たちはこれが本当か知っていますか?誰がこれをチェックしますか?それは完全に些細なことですが、それがどうしたのでしょう?私は、多くの違う要素に関して、要素の名前とその属性との間に空白を持ったテストファイルを 50 でも 100 でも作り、それらを実行するためにテストのリストに追加することができ、それは誰にとっても問題ありません。実際にこの挙動をテストするには実際 500 テストファイルをようするでしょう。それは実際問題ではありません。
つまり、私が言いたいことは、アイディアがあるならテストを作ってください。本当に。少な過ぎるよりより多くのテストを持っている方がより良いのです。
2 番目と 3 番目の reftest
これらのテストのために以下のファイルを作ってください:
spaces1.html:
<html><head><title>spaces1</title></head> <body> X X </body></html>
spaces2.html:
<html><head><title>spaces2</title></head> <body> X X </body></html>
spaces3.html:
<html><head><title>spaces3</title></head> <body> X X </body></html>
spaces4.html:
<html><head><title>spaces4</title></head> <body> X X </body></html>
reftests.txt:
== spaces1.html spaces2.html != spaces3.html spaces4.html
最初の2 つのファイル (spaces1.html と spaces2.html) は空白 (ASCII の 0x20 と等しい文字)が non-breaking 空白のHTML エンティティと等しい視覚構造をつくるかを確認しているだけです。 2 つめのペアのファイル (spaces3.html と spaces4.html) は2 つの普通の空白が2 つの non-breaking 空白と同じ視覚構造を生成しない ことを確認しています。
それらを実行すると、以下を見ることができます。:
$ /Users/ray/mo/browser/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox -P minefield1 -reftest ./reftests.txt 2>&1 | grep REFTEST REFTEST PASS: file:///Users/ray/mo/spaces1.html REFTEST PASS: (!=) file:///Users/ray/mo/spaces3.html $
素晴らしい!
他の比較
また、結果として生じるはずの視覚構造の画像に対してマークアップをテストする reftest も作成可能であるべきなのに注意してください。これはたぶん上で説明された理由により、より危ういテストでしょう。 しかしそれは必要ないかもしれません。
例えば、ある特定のマークアップが特定のサンスクリット語のグリフを生成すべきと言ってみましょう。それをどうやってテストしますか?ひとつには表示されるべきグリフの「写真を撮り」、リファレンスページがその画像を <img> 要素で埋め込むことで可能になるべきです。
これが機能するかどうかの、より多くの調査は確実に保証されています。これの実験は、それが人が望んでいるだろうほど簡単でないことを示しました。結果を見守りましょう。
ここにソースの中の reftest opportunities files のリストがあります。テストされるべくチェックインされたファイルです。おそらく、ブラウザでページを開き、それらを眺めて正しいかどうかをみていたのでしょうこれらの内いくつが、reftest としても利用可能かを言うのは困難です。もしファイルがあるバグと関連付けられていたら、そのバグは試験されるべきです。私はバグの HTML フィルに問題がありますが、チェックインされたバージョンでは「クリーンアップ」されテストには有効ではないケースも見ました。
過去、Mozilla は HTML 生成ツールを使ってきました。htmlgen ツールはこの例は一つです。このようなツールはファイルを試験する reftest があることで今ではより便利になりました。HTML とCSS を興味深い方法か、一般的ではない方法で結びつけるファイルを生成するのにも役立つでしょう。
参照
- https://weblogs.mozillazine.org/qa/ar...t_reftest.html
- https://www.nabble.com/Please-add-%22...-t2791203.html
layout/tools/reftest/README.txt