mozilla

Compare Revisions

Creating reftest-based unit tests

Change Revisions

Revision 27082:

Revision 27082 by jlebar on

Revision 27083:

Revision 27083 by Stechz on

Title:
Creating reftest-based unit tests
Creating reftest-based unit tests
Slug:
Creating_reftest-based_unit_tests
Creating_reftest-based_unit_tests
Tags:
"Automated testing", "Developing Mozilla"
"Automated testing", "Developing Mozilla"
Content:

Revision 27082
Revision 27083
nn8      The reftest harness can be thought of as comparing two visu
 >al constructs. If the visual constructs produced by two files are
 > identical, the test passes. If they differ, the test fails. The 
 >power of the tool comes from the fact that there is more than one
 > way to achieve any given visual effect in a browser. So, if the 
 >effect of complex markup is being tested, put that complex markup
 > into a page and create another page that uses simple markup to a
 >chieve the same visual effect. Reftest will then compare them and
 > verify whether they produce the same visual construct.
9    </p>
10    <p>
nn13    <p>
14      This idea can seem odd when first encountered. Automated te
 >sting usually compares output against an invariant, a "gold stand
 >ard", that is determined to be correct. If one has software that 
 >multiplies numbers, one wants a regression test to show that 2 * 
 >2 continues to be calculated to be 4, not something similar to bu
 >t not quite exactly 4. But an operating system does change with t
 >ime. It is not invariant. And a browser may change the visual eff
 >ect produced by a tag while still being compliant with relevant s
 >tandards. For example, the HTML 4.01 specification at the W3C spe
 >cifies that text inside of a <code>&lt;blockquote&gt;</code> will
 > be indented, but it does not specify the number of pixels of the
 > indentation. If a browser changes the depth of the indenting and
 > the visual construct is tested against an invariant, the test wo
 >uld appear to fail. But the test should not fail, unless the <cod
 >e>"&lt;blockquote&gt;"</code> element did not cause any indentati
 >on at all. If a regression test harness has false failures, it ma
 >kes the harness not trustworthy and the harness will not be used.
15    </p>
16    <h1>
17      Running reftest-based unit tests
18    </h1>
19    <p>
20      To run all the reftests, run:
21    </p>
22    <pre>
23make -C $(OBJDIR) reftest
24</pre>
25    <p>
26      If you want to run a particular set of reftests, use <code>
 >TEST_PATH</code>:
27    </p>
28    <pre>
29TEST_PATH=path/from/sourcedir/reftest.list make -C $(OBJDIR) reft
 >est
30</pre>
31    <h3>
32      Running IPC reftests
33    </h3>
34    <p>
35      Reftests can also be run in a separate process, which can d
 >iffer from same-process rendering in significant ways. Currently,
 > IPC reftests are only being run on Linux. To run:
36    </p>
37    <pre>
38MOZ_LAYERS_FORCE_SHMEM_SURFACES=1 make -C $(OBJDIR) reftest-ipc
39</pre>
40    <h1 class="first" id="title">
41      Creating reftest-based unit tests&nbsp;
42    </h1>
t14      The reftest harness can be thought of as comparing two visut
>al constructs. If the visual constructs produced by two files are 
> identical, the test passes. If they differ, the test fails. The  
>power of the tool comes from the fact that there is more than one 
> way to achieve any given visual effect in a browser. So, if the  
>effect of complex markup is being tested, put that complex markup 
> into a page and create another page that uses simple markup to a 
>chieve the same visual effect. Reftest will then compare them and 
> verify whether they produce the same visual construct. 
15    </p>
16    <p>
17      This idea can seem odd when first encountered. Automated te
>sting usually compares output against an invariant, a "gold stand 
>ard", that is determined to be correct. If one has software that  
>multiplies numbers, one wants a regression test to show that 2 *  
>2 continues to be calculated to be 4, not something similar to bu 
>t not quite exactly 4. But an operating system does change with t 
>ime. It is not invariant. And a browser may change the visual eff 
>ect produced by a tag while still being compliant with relevant s 
>tandards. For example, the HTML 4.01 specification at the W3C spe 
>cifies that text inside of a <code>&lt;blockquote&gt;</code> will 
> be indented, but it does not specify the number of pixels of the 
> indentation. If a browser changes the depth of the indenting and 
> the visual construct is tested against an invariant, the test wo 
>uld appear to fail. But the test should not fail, unless the <cod 
>e>"&lt;blockquote&gt;"</code> element did not cause any indentati 
>on at all. If a regression test harness has false failures, it ma 
>kes the harness not trustworthy and the harness will not be used. 
18    </p>
19    <p>
20      An example may make this clear. It is a silly example, but 47      It is a silly example, but this will step you through creat
>this will step you through creating your first reftest.>ing your first reftest.

Back to History