diff options
Diffstat (limited to 'files/ja/browser_chrome_tests/index.html')
| -rw-r--r-- | files/ja/browser_chrome_tests/index.html | 118 |
1 files changed, 0 insertions, 118 deletions
diff --git a/files/ja/browser_chrome_tests/index.html b/files/ja/browser_chrome_tests/index.html deleted file mode 100644 index d5333e77e7..0000000000 --- a/files/ja/browser_chrome_tests/index.html +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Browser chromeテスト -slug: Browser_chrome_tests -tags: - - Automated testing - - Developing Mozilla - - NeedsUpdate -translation_of: Mozilla/Browser_chrome_tests ---- -<p>Browser chrome テストスイートは、JavaScript を用いてアプリケーションの Chrome ウィンドウをテストできるように設計された、自動テストフレームワークです。現在の所、JavaScript のコードを Firefox のメインのブラウザウィンドウと同じスコープで実行し、結果を <a href="/ja/Mochitest" title="ja/Mochitest">Mochitest テストフレームワーク</a>と同じ関数を使って報告することができます。Browser chrome テストスイートは Mochitest が無効化されたビルド（--disable-tests オプションを付けたビルド）では動作しません。</p> - -<h3 id="Running_the_browser_chrome_tests" name="Running_the_browser_chrome_tests">Browser chrome テストを実行する</h3> - -<p>Mochitest を実行するには、あなたが行った変更を含めて、まず <a href="/ja/Developer_Guide/Build_Instructions" title="ja/Build_Documentation">Mozilla をビルドする</a>必要があります。その後、以下を実行します。</p> - -<pre>./mach mochitest -f browser</pre> - -<p>このコマンドは、あなたがビルドした Mozilla を起動した上で、「browser chrome tests」というウィンドウを開き、テストを実行します。実行結果はそのウィンドウ内と標準出力に報告されます。</p> - -<p>特定のグループのテストのみを実行することもできます。その場合は、<a class="internal" href="/ja/Mochitest" title="ja/Mochitest">Mochitest</a> と同様に、Mozilla ソースツリー内のディレクトリまたはテストファイルのパスを引数として指定します。パスがディレクトリを指している場合は、そのディレクトリとサブディレクトリに含まれるすべてのテストが実行されるでしょう。</p> - -<p>例えば、<code>browser/base/content/test</code> のテストを実行するコマンドは以下のようになります：</p> - -<pre>./mach mochitest -f browser browser/base/content/test/</pre> - -<p>mach を使わないのであれば、以下のようにします。</p> - -<pre>TEST_PATH=<path_to_the_tests> make -C <objdir> mochitest-browser-chrome</pre> - -<p>デバッガ内でテストを実行するには以下のようにして下さい：</p> - -<pre>./mach mochitest -f browser --debugger gdb browser/base/content/test/</pre> - -<p>その他のオプションについては、<code>./mach help mochitest-browser</code> で見ることができます。</p> - -<h3 id="Writing_browser_chrome_tests" name="Writing_browser_chrome_tests">Browser chrome テストを書く</h3> - -<p>Browser chrome テストはブラウザウィンドウのグローバルな変数スコープで実行される JavaScript のコード片です。単純なテストの例はこのようになります：</p> - -<pre class="brush: js language-js"> function test() { - ok(gBrowser, "gBrowser exists"); - is(gBrowser, getBrowser(), "gBrowser and tBrowser() are the same"); - } -</pre> - -<p>関数<code>test()</code> は、テストが実行される時にテストハーネスによって呼び出されます。テストのファイルには他の関数を含める事ができますが、それらは <code>test()</code> によって呼び出される物以外は無視されます。</p> - -<p>gBrowser は、<a href="https://developer.mozilla.org/ja/docs/">browser.js</a>内で定義されている、<a href="https://developer.mozilla.org/ja/docs/XUL/tabbrowser">tabbrowser</a>要素（<a href="https://developer.mozilla.org/ja/docs/">browser.xul内で id="content"と指定されている tabbrowser</a>）への参照です。</p> - -<div class="note">注意： 関数や変数に名前を付ける時には注意してください。テストファイルの内容はブラウザウィンドウと同じスコープで実行されるため、変数名が衝突すると、テストの実行時に問題が起こる可能性があります。テスト用のコードによる副作用をなるべく少なくすると同時に、他のテストに影響を与えないために、テストの実行が終わった後は「クリーンアップ」を自ら行うようにしてください。</div> - -<p>比較関数は Mochitests でサポートされているものと全く同じ物を使えます。詳細を知りたい場合は、Mochitest のドキュメントの<a href="/ja/Mochitest#How_do_the_comparison_functions_work.3F" title="ja/Mochitest#How_do_the_comparison_functions_work.3F">比較関数がどのように動作するか</a>を参照してください。 グローバルのスコープに定義された「EventUtils」オブジェクトから、<a class="external" href="http://lxr.mozilla.org/mozilla/source/testing/mochitest/tests/SimpleTest/EventUtils.js">EventUtils ヘルパ関数</a> を利用する事もできます。</p> - -<p>テストファイルの名前は「browser_」で始まり、拡張子は「.js」でなければなりません。このパターンに一致しないファイルはテストハーネスに よって無視されます。単にバグ番号だけを使うよりも、より問題の内容を読み取りやすいファイル名にすることが、強く推奨されます。</p> - -<p>あなたは、各テストで共通のユーティリティやヘルパーを <code>head.js</code> というファイル（このファイルは browser-chrome テストと同じフォルダに置かれなければなりません）にまとめる事ができます。このファイルの内容は、同じフォルダに存在する各テストに対して、テストのス コープに注入されることになります。<code>head.js</code> のメインのスコープでのあらゆる関数呼び出しは、メインの <code>test() </code> が実行されるよりも前に行われる事に注意してください。</p> - -<h4 id="Test_functions" name="Test_functions">非同期のテスト</h4> - -<p>テストスイートでは、Mochitest で用意されている関数と同じ名前の関数を使う事で、非同期のテストも実行することができます。<code>test()</code> の実行が終わるまで待ってから実行結果の報告を受け取りたい場合、<code>test()</code> の中で <code>waitForExplicitFinish()</code> を呼んでください。テストが完了した後には finish()を呼びます。テストが完了するまであまりに長い時間がかかった場合、テストハーネスはそのテストを FAILED（失敗）と見なす事に留意してください（現在の所、タイムアウトまでの時間は 30秒です）。</p> - -<pre class="brush: js language-js"> function test() { - waitForExplicitFinish(); - setTimeout(completeTest, 1000); - } - - function completeTest() { - ok(true, "Timeout ran"); - finish(); - } -</pre> - -<p>もしあなたのテストがランダムにタイムアウトした時、それが処理に時間がかかりすぎるせいで起こっていると考えるならば、タイムアウトまでの時間を延ばす事ができます。<strong>これは完全な解決ではなく、あなたはなぜそのテストに長い時間がかかっているのか（テストの設計が良くないせいだったり、パフォーマンス上の問題があるせいだったりはしないか）を調査することが望ましいという事に気をつけて下さい。</strong> 本当にタイムアウトの時間を延ばす前に、もしテストをもっと短く書く事ができるようであれば、もっと小さいテストに分割したり、あるいは、なぜ長い時間がかかっているのか原因を調べたりといった対策を取るべきです！</p> - -<pre class="brush: js language-js"> function test() { - // requestLongerTimeout は既定のタイムアウト秒数の 30秒を何倍するかを整数で受け取ります。 - // 2 であれば「合計で 60秒（2×30秒）待つ」という事になります。 - requestLongerTimeout(2); - waitForExplicitFinish(); - - setTimeout(completeTest, 40000); - } - - function completeTest() { - ok(true, "Timeout did not ran"); - finish(); - }</pre> - -<h4 id="Test_functions" name="Test_functions">テスト内での例外</h4> - -<p><code>test()</code>内で投げられたあらゆる例外は、捕捉され、テストにおいて失敗として報告されます。<code>test()</code> の外で投げられた例外（タイムアウトした場合、イベントハンドラ内での例外など）は捕捉されませんが、タイムアウトしたテストについては、それらが <code>finish()</code> の実行を妨げた場合は実行結果において報告されます。</p> - -<h4 id="Test_functions" name="Test_functions">テスト実行後のクリーンアップ</h4> - -<p>テストを実行し終えた後に何らかの特別なクリーンアップ処理を行う必要がある場合は、テストが完了した後に必ず呼ばれる、クリーンアップ用の関数を登録する事ができます。あなたは <code>registerCleanupFunction()</code> をテストの中の任意の時点で（そのフォルダの中のすべてのテストに対してクリーンアップ用の関数を登録する必要があるのなら、<code>head.js</code> の中でも）呼ぶ事ができます。クリーンアップ用の関数は必要なだけ任意の個数登録できることに注意してください。クリーンアップ用関数はまた、テストがタイムアウトした時にも必ず呼ばれますので、次に実行されるテストを汚染してそれらが失敗してしまうといった事が起こらないように強制する事ができます。</p> - -<pre class="brush: js language-js">registerCleanupFunction(function() { - // テスト環境のクリーンアップ処理をここに書く -}); - -function test() { - // テストに関する処理をここに書く -}</pre> - -<p><strong>テストを書く時は、失敗に備えて下さい。</strong><code><code>registerCleanupFunction()</code></code>は何があっても必ず実行されるので、<code>registerCleanupFunction()</code> を書くことは、テストの成功後に自分でクリーンアップ処理を行うよりも<em>より</em>望ましいです。例えば、テストの中で設定値を変更していても、それを<em>必ず</em>リセットするようにしておけば、あなたのテストは他のテストに何も影響を及ぼしません。</p> - -<h3 id="Adding_a_new_browser_chrome_test_to_the_tree" name="Adding_a_new_browser_chrome_test_to_the_tree">新しい Browser chrome テストをツリーに追加する</h3> - -<p>新しい Browser chrome テストをツリーに追加するには、テストと同じフォルダにある <code>browser.ini</code> の中にそのファイルを追加して下さい。また、テストファイルの名前は browser chrome テストである事が分かるように "browser_" で始まるようにしなければならない事も憶えておいて下さい。もしディレクトリ内に最初のテストを追加する場合には、<code>support-files</code>内に <code>head.js</code> も含まれている事を確認しておいて下さい。</p> - -<h4 id="Support-files" name="Support-files">Support-files</h4> - -<p><code>browser.ini</code>内の support-file セクションに追加されたサポートファイルは、<code>https://example.com/browser/[path_to_file]</code> <code>あるいは chrome://mochitests/content/browser/[path_to_file]</code>で参照できるようになります。</p> - -<p>{{ languages( { "en": "En/Browser_chrome_tests" } ) }}</p> - -<hr> -<p> </p> |