Reducing testcases

  • Revision slug: Reducing_testcases
  • Revision title: Reducing testcases
  • Revision id: 94917
  • Created:
  • Creator: Jesse
  • Is current revision? No
  • Comment De-bold

Revision Content

A reduced testcase is the simplest possible Web page that still demonstrates the bug. A bug report with a reduced testcase is easier to tackle than a bug report that merely refers to a web page that Firefox displays incorrectly.

Why make reduced testcases?

  • Every hour Gecko engineers spend decomposing bug reports is an hour they can't spend fixing bugs.
  • Overworked engineers tend to focus on bugs with testcases, so writing a testcase is the best and most productive way to vote for a bug.
  • Writing a reduced testcase ensures that the bug report will still be useful if the page changes.
  • Once the bug is fixed, a reduced testcase can be converted into an automated test, ensuring that the problem will not return.

How do I make a reduced testcase?

To turn a web page that shows a bug into a reduced test case:

  1. Download a recent nightly build of Firefox to avoid wasting time on a bug that is already fixed.
  2. Download the Web page that shows the bug to your local machine.
    • Use the "Web Page, Complete" option in the save dialog to download all linked files, including JavaScript (<tt>.js</tt>), CSS (.css), frameset (.html), and image files.
    • Or, use the "Web Page, HTML only" option and then add <base href="original url"> to the top of the HEAD element to maintain relative URLs.
  3. Using a text editor, remove irrelevant HTML markup, CSS rules, and lines of JavaScript from the page. As you remove parts of the page, reload it in Firefox to make sure it still reproduces the bug.
  4. When you've cut away as much HTML, CSS, and JavaScript as you can, and cutting away any more causes the bug to disappear, you're done!

What do I do with a reduced testcase?

Once you have made a reduced testcase, attach the testcase to the bug report using the "Add an attachment" link. Then enter "testcase" into the Keywords1 field so engineers know the bug is ready to be crushed.

Now that you know what HTML tags or CSS properties are involved in triggering the bug, search Bugzilla again to determine whether others have reported similar problems. You may learn that Gecko's behavior is intentional, in which case you can turn1 the bug report into a (tech evangelism bug). Or you may learn that the bug is a duplicate of another open bug report.

Consider rewriting the bug's summary1 to reflect the testcase, so it can be found by someone doing a similar search. For example, "Can't open dropdown in table in position:relative span" is more likely to be found than "Can't open this page's dropdown".

1 A standard Bugzilla account does not have sufficient permission to add keywords or change a bug summary. After you have created testcases for two bugs, mail Gerv with links to the two bugs, and he will upgrade your permissions.

External files

If the testcase uses multiple files, try to modify the testcase so all of the information is in a single file.

  • Replace <link rel="stylesheet" href="..."> with a <style> element containing the text of the stylesheet.
  • Replace <script src="..."></script> with a <script> element containing the text of the script.
  • Replace src URLs in IMG and IFRAME tags with equivalent data: URIs using the data: URI kitchen. Note that Internet Explorer 7 and below did not support data: URIs, so you shouldn't use this technique if the bug is about a difference between IE7 and Gecko.

As a last resort, you can upload ancillary files to Bugzilla, then modify the main file to point to the URLs of the attachments before uploading it. This is better than uploading a zip file because it allows the testcase to be viewed merely by clicking the link in Bugzilla.

Standards and quirks modes

Gecko uses the page's document type declaration to decide whether to display the page in "Quirks mode", "Almost Standards mode", or "Standards Compliance mode". Firefox's "Page Info" window can show you which mode a page uses, but it does not yet distinguish between Almost Standards mode and Standards Compliance mode (bug 154359).

If a page looks bad in Standards Compliance mode, try removing the doctype from the top of the file. If the Web page then display correctly, then the Web page author probably is relying on the (incorrect) rendering behaviors of older browsers but mistakenly asking browsers to render it according to modern web standards. Search for the name of the feature along with "quirk" or "standards mode" to find related bug reports.

Increasing testcase clarity

It is best for a reduced testcase to use a standards-mode doctype. This adds to the size of the file, but it effectively makes the testcase simpler by instructing Gecko not to apply compatibility quirks such as the rules in quirk.css. We prefer the HTML5 doctype

<!DOCTYPE html>

If the bug involves tables or margins, you can make it easier to visualize the bug by adding borders or outlines.

You can also increase the clarity of a testcase by using simpler elements:

  • Replace block elements such as P with the generic block element DIV.
  • Replace inline elements such as B, I, EM, STRONG, and even A with the generic inline element SPAN.
  • Replace an image with an inline-block element of the same size, if you don't mind excluding browsers that don't support inline-block.

Useful tools

  • A text editor with syntax highlighting can make it easier to scan code as you reduce it.
    • Windows: Notepad++ highlights HTML markup and embedded scripts.
    • Mac: TextWrangler highlights HTML markup, embedded stylesheets (if they are marked with type="text/css"), and embedded scripts (if they are marked with type="text/javascript").
  • Firebug lets you view the DOM tree of a page and see what CSS rules apply to each element.
  • DOM Inspector lets you do many of the same things as Firebug. Its UI is less elegant, but it uses fewer resources.
  • Web development Bookmarklets such as "ancestors", "show blocks", "view scripts", "view style sheets" and "edit styles" can be useful for reducing testcases.
  • The Real-Time HTML Editor lets you build testcases from the ground up.
  • Lithium lets you automate the process of reducing testcases for bugs that can be detected automatically, such as crashes and layout-instability bugs.
  • The W3C HTML Validator points out markup errors, which are sometimes the reason the page looks bad in Firefox. You can also use the validator to ensure that your reduced testcase file is valid HTML.

Original document information

  • Title: The Gecko BugAThon
  • Author: Eric Krock
  • Other Contributors: Gervase Markham, Bernd Mielke

Revision Source

<p>A reduced testcase is the simplest possible Web page that still demonstrates the bug.  A bug report with a reduced testcase is easier to tackle than a bug report that merely refers to a web page that Firefox displays incorrectly.
</p>
<h3 name="Why_make_reduced_testcases.3F"> Why make reduced testcases? </h3>
<ul><li> Every hour Gecko engineers spend decomposing bug reports is an hour they can't spend fixing bugs.
</li><li> Overworked engineers tend to focus on bugs with testcases, so writing a testcase is the best and most productive way to vote for a bug.
</li><li> Writing a reduced testcase ensures that the bug report will still be useful if the page changes.
</li><li> Once the bug is fixed, a reduced testcase can be converted into an <a href="en/Mozilla_automated_testing">automated test</a>, ensuring that the problem will not return.
</li></ul>
<h3 name="How_do_I_make_a_reduced_testcase.3F"> How do I make a reduced testcase? </h3>
<p>To turn a web page that shows a bug into a reduced test case:
</p>
<ol><li> Download a <a class="external" href="https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk">recent nightly build of Firefox</a> to avoid wasting time on a bug that is already fixed.
</li><li> Download the Web page that shows the bug to your local machine.
<ul><li> Use the "Web Page, Complete" option in the save dialog to download all linked files, including JavaScript (<tt>.js</tt>), CSS (<code>.css</code>), frameset (<code>.html</code>), and image files.
</li><li> Or, use the "Web Page, HTML only" option and then add &lt;base href="original url"&gt; to the top of the HEAD element to maintain relative URLs.
</li></ul>
</li><li> Using a text editor, remove irrelevant HTML markup, CSS rules, and lines of JavaScript from the page.  As you remove parts of the page, reload it in Firefox to make sure it still reproduces the bug.
</li><li> When you've cut away as much HTML, CSS, and JavaScript as you can, and cutting away any more causes the bug to disappear, you're done!
</li></ol>
<h3 name="What_do_I_do_with_a_reduced_testcase.3F"> What do I do with a reduced testcase? </h3>
<p>Once you have made a reduced testcase, attach the testcase to the bug report using the "Add an attachment" link.  Then enter "<kbd>testcase</kbd>" into the Keywords<sup>1</sup> field so engineers know the bug is ready to be crushed.
</p><p>Now that you know what HTML tags or CSS properties are involved in triggering the bug, search Bugzilla again to determine whether others have reported similar problems.  You may learn that Gecko's behavior is intentional, in which case you can turn<sup>1</sup> the bug report into a (<a class="external" href="http://www.mozilla.org/projects/tech-evangelism/site/procedures.html">tech evangelism bug</a>).  Or you may learn that the bug is a duplicate of another open bug report.
</p><p>Consider rewriting the bug's summary<sup>1</sup> to reflect the testcase, so it can be found by someone doing a similar search.  For example, "Can't open dropdown in table in position:relative span" is more likely to be found than "Can't open this page's dropdown".
</p><p><sup style="color: red;">1</sup> A standard Bugzilla account does not have sufficient permission to add keywords or change a bug summary. After you have created testcases for two bugs, mail <a class="external" href="mailto:gerv@mozilla.org">Gerv</a> with links to the two bugs, and he will upgrade your permissions.
</p>
<h3 name="External_files"> External files </h3>
<p>If the testcase uses multiple files, try to modify the testcase so all of the information is in a single file.
</p>
<ul><li> Replace &lt;link rel="stylesheet" href="..."&gt; with a &lt;style&gt; element containing the text of the stylesheet.
</li><li> Replace &lt;script src="..."&gt;&lt;/script&gt; with a &lt;script&gt; element containing the text of the script.
</li><li> Replace src URLs in IMG and IFRAME tags with equivalent data: URIs using the <a class="external" href="http://software.hixie.ch/utilities/cgi/data/data">data: URI kitchen</a>.  Note that Internet Explorer 7 and below did not support data: URIs, so you shouldn't use this technique if the bug is about a difference between IE7 and Gecko.
</li></ul>
<p>As a last resort, you can upload ancillary files to Bugzilla, then modify the main file to point to the URLs of the attachments before uploading it.  This is better than uploading a zip file because it allows the testcase to be viewed merely by clicking the link in Bugzilla.
</p>
<h3 name="Standards_and_quirks_modes"> Standards and quirks modes </h3>
<p>Gecko <a href="en/Mozilla's_DOCTYPE_sniffing">uses the page's document type declaration</a> to decide whether to display the page in <a href="en/Mozilla_Quirks_Mode_Behavior">"Quirks mode"</a>, <a href="en/Gecko's_%22Almost_Standards%22_Mode">"Almost Standards mode"</a>, or "Standards Compliance mode".  Firefox's "Page Info" window can show you which mode a page uses, but it does not yet distinguish between Almost Standards mode and Standards Compliance mode (<a class="external" href="https://bugzilla.mozilla.org/show_bug.cgi?id=154359">bug 154359</a>).
</p><p>If a page looks bad in Standards Compliance mode, try removing the doctype from the top of the file.  If the Web page then display correctly, then the Web page author probably is relying on the (incorrect) rendering behaviors of older browsers but mistakenly asking browsers to render it according to modern web standards.  Search for the name of the feature along with "quirk" or "standards mode" to find related bug reports.
</p>
<h3 name="Increasing_testcase_clarity"> Increasing testcase clarity </h3>
<p>It is best for a reduced testcase to use a standards-mode doctype.  This adds to the size of the file, but it effectively makes the testcase simpler by instructing Gecko not to apply compatibility quirks such as the rules in quirk.css.  We prefer the HTML5 doctype
</p>
<pre class="eval">&lt;!DOCTYPE html&gt;
</pre>
<p>If the bug involves tables or margins, you can make it easier to visualize the bug by adding borders or outlines.
</p><p>You can also increase the clarity of a testcase by using simpler elements:
</p>
<ul><li> Replace block elements such as P with the generic block element DIV.
</li><li> Replace inline elements such as B, I, EM, STRONG, and even A with the generic inline element SPAN.
</li><li> Replace an image with an inline-block element of the same size, if you don't mind excluding browsers that don't support inline-block.
</li></ul>
<h3 name="Useful_tools"> Useful tools </h3>
<ul><li> <b>A text editor with <a class="external" href="http://en.wikipedia.org/wiki/Syntax_highlighting">syntax highlighting</a></b> can make it easier to scan code as you reduce it.
<ul><li> Windows: <a class="external" href="http://notepad-plus.sourceforge.net/uk/site.htm">Notepad++</a> highlights HTML markup and embedded scripts.
</li><li> Mac: <a class="external" href="http://www.barebones.com/products/textwrangler">TextWrangler</a> highlights HTML markup, embedded stylesheets (if they are marked with type="text/css"), and embedded scripts (if they are marked with type="text/javascript").
</li></ul>
</li><li> <b><a class="external" href="http://getfirebug.com/">Firebug</a></b> lets you view the DOM tree of a page and see what CSS rules apply to each element.
</li><li> <b><a class="external" href="https://addons.mozilla.org/en-US/firefox/addon/6622">DOM Inspector</a></b> lets you do many of the same things as Firebug.  Its UI is less elegant, but it uses fewer resources.
</li><li> <b><a class="external" href="http://www.squarefree.com/bookmarklets/webdevel.html">Web development Bookmarklets</a></b> such as "ancestors", "show blocks", "view scripts", "view style sheets" and "edit styles" can be useful for reducing testcases.
</li><li> <b><a class="external" href="http://www.squarefree.com/htmledit/">The Real-Time HTML Editor</a></b> lets you build testcases from the ground up.
</li><li> <b><a class="external" href="http://www.squarefree.com/2007/09/15/introducing-lithium-a-testcase-reduction-tool/">Lithium</a></b> lets you automate the process of reducing testcases for bugs that can be detected automatically, such as crashes and layout-instability bugs.
</li><li> <b><a class="external" href="http://validator.w3.org/">The W3C HTML Validator</a></b> points out markup errors, which are sometimes the reason the page looks bad in Firefox.  You can also use the validator to ensure that your reduced testcase file is valid HTML.
</li></ul>
<div class="originaldocinfo">
<h2 name="Original_document_information"> Original document information </h2>
<ul><li> Title: <a class="external" href="http://www-archive.mozilla.org/newlayout/bugathon.html">The Gecko BugAThon</a>
</li><li> Author: Eric Krock
</li><li> Other Contributors: Gervase Markham, Bernd Mielke
</li></ul>
</div>
Revert to this revision