Compare Revisions

Compiled-code automated tests

Change Revisions

Revision 136837:

Revision 136837 by Waldo on

Revision 136838:

Revision 136838 by b0rland on

Title:
Compiled-code automated tests
Compiled-code automated tests
Slug:
Compiled-code_automated_tests
Compiled-code_automated_tests
Tags:
"Automated testing", "Developing Mozilla"
"Automated testing", "Developing Mozilla"
Content:

Revision 136837
Revision 136838
n16    <h2>n16    <h2 id="The_structure_of_a_compiled-code_test">
n69      There are a couple things to note that aren't demonstrated n69      There are a couple things to note that aren't demonstrated 
>by this skeleton. First, note that a test failure doesn't cause t>by this skeleton. First, note that a test failure doesn't cause t
>he test to immediately fail. While it's possible to write tests t>he test to immediately fail. While it's possible to write tests t
>hat fail as early as possible, usually it's possible to run multi>hat fail as early as possible, usually it's possible to run multi
>ple tests and only report failure at the end, which can save the >ple tests and only report failure at the end, which can save the 
>frustrated developer who breaks your test the trouble of fixing e>frustrated developer who breaks your test the trouble of fixing e
>ach failure individually. Second, a test which fails should do so>ach failure individually. Second, a test which fails should do so
> by printing an error message using <code>fail()</code> and retur> by printing an error message using <code>fail()</code> and retur
>ning a failure code. When possible, the error should be printed a>ning a failure code. When possible, the error should be printed a
>s early as possible and propagated up the call stack without prin>s early as possible and propagated up the call stack without prin
>ting further errors (note how in the example the <code>TestFoo()<>ting further errors (note how in the example the <code>TestFoo()<
>/code> doesn't have a corresponding printed message, because <cod>/code> doesn't have a corresponding printed message, because <cod
>e>TestFoo</code>'s definition should do so before returning a fai>e>TestFoo</code>'s definition should do so before returning a fai
>lure code), but if an error must be printed multiple times, that'>lure code), but if an error must be printed multiple times, that'
>s fine. Use the <code>and</code> <code>passed()</code> functions >s fine. Use the <code>fail() and</code> <code>passed()</code> fun
>in the test harness provides to report errors. Third, it's fine t>ctions in the test harness provides to report errors. Third, it's
>o print out pass messages using the <code>passed()</code> functio> fine to print out pass messages using the <code>passed()</code> 
>n at the end of tests, as occurs at the end of <code>TestFoo()</c>function at the end of tests, as occurs at the end of <code>TestF
>ode>, but if you're printing more than 10-15 you should consider >oo()</code>, but if you're printing more than 10-15 you should co
>being more selective in what you print. The intent is to give inf>nsider being more selective in what you print. The intent is to g
>ormation about test progress, not to overwhelm the screen or tind>ive information about test progress, not to overwhelm the screen 
>erbox logs.&nbsp; (Yes, I'm looking at you, {{ Source("netwerk/te>or tinderbox logs.&nbsp; (Yes, I'm looking at you, {{ Source("net
>st/TestCookie.cpp") }}!)>werk/test/TestCookie.cpp") }}!)
n71    <h2>n71    <h2 id="Making_the_test_compile_and_link">
n86    <h2>n86    <h2 id="Functionality_provided_by_TestHarness.h">
n92    <h2>n92    <h2 id="Running_the_tests">
t98    <h2>t98    <h2 id="Examples">

Back to History