Pruebas automatizadas de Mozilla

  • Enlace amigable (slug) de la revisión: Pruebas_automatizadas_de_Mozilla
  • Título de la revisión: Pruebas automatizadas de Mozilla
  • Id de la revisión: 123920
  • Creada:
  • Creador: RickieesES
  • ¿Es la revisión actual? No
  • Comentario /* Mochitest */

Contenido de la revisión

{{wiki.template('Traducción', [ "inglés", "Mozilla_automated_testing", "en" ])}}

Una vez acabada, esta página proporcionará un compendio de opciones para pruebas automatizadas disponibles para los desarrolladores de Mozilla con enlaces a más documentación.

La mayoría de las pruebas automatizadas deberían ejecutarse sobre make check. Cómo añadir una prueba en el momento de compilar describe los pasos requeridos para añadir un programa de pruebas arbitrario al conjunto de tests. Dependiendo de lo que se necesite probar, puede usarse uno de los siguientes frameworks disponibles:

xpcshell: make check

Con las ayudas para pruebas de xpcshell escribes pruebas unitarias en JavaScript. El código se ejecutará más tarde en xpcshell, que es una consola JS con capacidad para XPConnect. Esto significa que tu código puede acceder a componentes XPCOM, pero no puede (fácilmente) abrir ventanas, probar el chrome de la aplicación, trabajar con el analizador HTML o usar DOM.

Hay disponible un servidor HTTP sencillo para su uso desde los tests xpcshell.

Mochitest

Mochitest es un framework basado en Mochikit para escribir pruebas. Las pruebas se ejecutan en el navegador, desde un servidor web local (proporcionado por Mochitest). Los scripts de inicio que lo acompañan conceden diversos privilegios a localhost (crea un nuevo perfil en cada ejecución). Como resultado, las pruebas unitarias son libres de solicitar privilegios UniversalXPConnect (acceso a componentes XPCOM), abrir ventanas emergentes, etc. Mochitest es una buena solución si realmente necesitas un navegador completo para probar un problema. Por ejemplo, un test reciente verifica que el envío de formularios funciona en iframes fijados a display:none. Hay una FAQ de Mochitest.

Reftest

{{template.Source("layout/tools/reftest/README.txt", "Layout Engine Visual Tests (reftest)")}}. Each test consists of two documents (e.g. HTML) - one of them containing test markup and the other containing reference markup. The system works by comparing the rendering of two documents.

reftest is now built and installed automatically when ENABLE_TESTS is on (default) and there are example tests in {{template.Source("layout/reftests")}}.

In order to run those example tests, you need to reference the reftests dir from the parent makefile ({{template.Source("layout/Makefile.in")}}) by adding DIRS += reftests in it above the rules.mk line. Now (after rebuilding or just running make in layout) you can use make lcheck in layout/tools/reftests to run the test suite.

[No, that doesn't actually seem to work. --Bzbarsky 20:39, 25 April 2007 (PDT)]

The results are being output to the system console and are not processed in any way for now.

  • You may need to edit the Makefile.in in reftests, as it's currently just a temporary solution ({{template.Bug(366579)}}).
    • In particular you may want to use a separate profile to run the tests (by creating a profile named "reftests" and adding -P reftests to the line invoking the application).
    • Windows users: just running make lcheck may not work as a /cygdrive/.. will get passed to the app. You may want to hardcode the file:/// URL to the manifest for now.
  • For more information, see {{template.Source("layout/tools/reftest/README.txt", "")}} and the tutorial on creating a reftest-based test.

jssh

Currently not used

jssh runs JavaScript code as chrome.

  • Rumored by davel to be slow
  • Requires an extension to be enabled at build time (via --enable-extensions=).
  • Works only on trunk. Needs to be post-branching merged back to 1.8
  • {{template.Bug(343199)}} has the patches to build jssh as a real extension
  • Works very nicely from ruby in win32 see firewatir

Further Reading

Please ignore the {{mediawiki.interwiki('wikimo', 'SoftwareTesting:Scratchpad', 'wikimo:SoftwareTesting:Scratchpad')}} page, and look at {{mediawiki.interwiki('wikimo', 'SoftwareTesting', 'wikimo:SoftwareTesting')}} only. The scratchpad is for works-in-progress, and is pretty much guaranteed to be stale or wrong.

There's also {{mediawiki.interwiki('wikimo', 'SoftwareTesting', 'wikimo:SoftwareTesting')}} and Automated testing tips and tricks if you're looking for something to read.

These are some additional efforts underway:

  • You can write standalone test programs in C/C++. This option can be used to test functionality not exposed via XPCOM.
    • {{template.Bug(343673)}} tracks one person's effort, but there has been no recent activity
    • {{template.Bug(346703)}} contains one example of how this might be done
  • JSUnit can be used to write tests that run as content in the browser. Particularly useful for DOM, parser tests, but can't do anything that requires chrome privileges.
    • JsUnit will most likely not be a make check target for the time being, since it needs a full browser instance.
    • {{mediawiki.interwiki('wikimo', 'SoftwareTesting#Ideas to Collect', 'wikimo:SoftwareTesting#Ideas_to_Collect')}} lists some jsunit examples.
    • Refer to documentation on {{mediawiki.interwiki('wikimo', 'SoftwareTesting:Tools:jsUnit', 'wikimo:SoftwareTesting:Tools:jsUnit')}} for more information.
    • Some XForms tests uses JsUnit, as an example

Existing Test Harnesses and Frameworks

(originally from {{mediawiki.interwiki('wikimo', 'SoftwareTesting:Catalog_of_Automated_Tests', 'wikimo:SoftwareTesting:Catalog_of_Automated_Tests')}})

Fuente de la revisión

<p>
</p><p>{{wiki.template('Traducción', [ "inglés", "Mozilla_automated_testing", "en" ])}}
</p><p>Una vez acabada, esta página proporcionará un compendio de opciones para pruebas automatizadas disponibles para los desarrolladores de Mozilla con enlaces a más documentación.
</p><p>La mayoría de las pruebas automatizadas deberían ejecutarse sobre <code>make check</code>. <a href="es/C%c3%b3mo_a%c3%b1adir_una_prueba_en_el_momento_de_compilar">Cómo añadir una prueba en el momento de compilar</a> describe los pasos requeridos para añadir un programa de pruebas arbitrario al conjunto de tests. Dependiendo de lo que se necesite probar, puede usarse uno de los siguientes <i>frameworks</i> disponibles:
</p>
<h3 name="xpcshell:_make_check"> xpcshell: make check </h3>
<p>Con <a href="es/Escribir_pruebas_unitarias_basadas_en_xpcshell">las ayudas para pruebas de xpcshell</a> escribes pruebas unitarias en JavaScript. El código se ejecutará más tarde en <a href="es/Xpcshell">xpcshell</a>, que es una consola JS con capacidad para <a href="es/XPConnect">XPConnect</a>. Esto significa que tu código puede acceder a componentes XPCOM, pero no puede (fácilmente) abrir ventanas, probar el chrome de la aplicación, trabajar con el analizador HTML o usar DOM.
</p><p>Hay disponible un <a href="es/Servidor_HTTP_para_pruebas_unitarias">servidor HTTP</a> sencillo para su uso desde los tests xpcshell.
</p>
<h3 name="Mochitest"> Mochitest </h3>
<p><a href="es/Mochitest">Mochitest</a> es un <i>framework</i> basado en <a class="external" href="http://mochikit.com/">Mochikit</a> para escribir pruebas. Las pruebas se ejecutan en el navegador, desde un servidor web local (proporcionado por Mochitest). Los <i>scripts</i> de inicio que lo acompañan conceden diversos privilegios a localhost (crea un nuevo perfil en cada ejecución). Como resultado, las pruebas unitarias son libres de solicitar privilegios UniversalXPConnect (acceso a componentes XPCOM), abrir ventanas emergentes, etc. Mochitest es una buena solución si realmente necesitas un navegador completo para probar un problema. Por ejemplo, un test reciente verifica que el envío de formularios funciona en iframes fijados a <code>display:none</code>. Hay una <a href="es/Mochitest#FAQ">FAQ de Mochitest</a>.
</p>
<h3 name="Reftest"> Reftest </h3>
<p>{{template.Source("layout/tools/reftest/README.txt", "Layout Engine Visual Tests (reftest)")}}. Each test consists of two documents (e.g. HTML) - one of them containing test markup and the other containing reference markup. The system works by comparing the rendering of two documents.
</p><p>reftest is now built and installed automatically when <code>ENABLE_TESTS</code> is on (default) and there are example tests in {{template.Source("layout/reftests")}}.
</p><p>In order to run those example tests, you need to reference the <code>reftests</code> dir from the parent makefile ({{template.Source("layout/Makefile.in")}}) by adding <code>DIRS += reftests</code> in it above the rules.mk line. Now (after rebuilding or just running <code>make</code> in <code>layout</code>) you can use <code>make lcheck</code> in <code>layout/tools/reftests</code> to run the test suite.
</p><p>[No, that doesn't actually seem to work.  --<a href="User:Bzbarsky">Bzbarsky</a> 20:39, 25 April 2007 (PDT)]
</p><p>The results are being output to the system console and are not processed in any way for now.
</p>
<ul><li> You may need to edit the <code>Makefile.in</code> in <code>reftests</code>, as it's currently just a temporary solution ({{template.Bug(366579)}}).
<ul><li> In particular you may want to use a separate profile to run the tests (by creating a profile named "reftests" and adding <code>-P reftests</code> to the line invoking the application).
</li><li> Windows users: just running <code>make lcheck</code> may not work as a <code>/cygdrive/..</code> will get passed to the app. You may want to hardcode the file:/// URL to the manifest for now.
</li></ul>
</li><li> For more information, see {{template.Source("layout/tools/reftest/README.txt", "")}} and <a href="es/Creating_reftest-based_unit_tests">the tutorial on creating a reftest-based test</a>.
</li></ul>
<h3 name="jssh"> jssh </h3>
<p><b>Currently not used</b>
</p><p><a class="external" href="http://croczilla.com/jssh">jssh</a> runs JavaScript code as chrome.
</p>
<ul><li> Rumored by davel to be slow
</li><li> Requires an extension to be enabled at build time (via <code>--enable-extensions=</code>).
</li><li> Works only on trunk.  Needs to be post-branching merged back to 1.8
</li><li> {{template.Bug(343199)}} has the patches to build jssh as a real extension
</li><li> Works very nicely from ruby in win32 see <a class="external" href="http://code.google.com/p/firewatir/">firewatir</a>
</li></ul>
<h3 name="Further_Reading"> Further Reading </h3>
<p>Please ignore the {{mediawiki.interwiki('wikimo', 'SoftwareTesting:Scratchpad', 'wikimo:SoftwareTesting:Scratchpad')}} page, and look at {{mediawiki.interwiki('wikimo', 'SoftwareTesting', 'wikimo:SoftwareTesting')}} only.  The scratchpad is for works-in-progress, and is pretty much guaranteed to be stale or wrong.
</p><p>There's also {{mediawiki.interwiki('wikimo', 'SoftwareTesting', 'wikimo:SoftwareTesting')}} and <a href="es/Automated_testing_tips_and_tricks">Automated testing tips and tricks</a> if you're looking for something to read.
</p><p>These are some additional efforts underway:
</p>
<ul><li> You can write standalone test programs in C/C++. This option can be used to test functionality not exposed via XPCOM. 
<ul><li> <i>{{template.Bug(343673)}} tracks one person's effort, but there has been no recent activity</i>
</li><li> <i>{{template.Bug(346703)}} contains one example of how this might be done</i>
</li></ul>
</li><li> <a class="external" href="http://www.jsunit.net/">JSUnit</a> can be used to write tests that run as content in the browser. Particularly useful for DOM, parser tests, but can't do anything that requires chrome privileges. 
<ul><li> JsUnit will most likely not be a make check target for the time being, since it needs a full browser instance.
</li><li> {{mediawiki.interwiki('wikimo', 'SoftwareTesting#Ideas to Collect', 'wikimo:SoftwareTesting#Ideas_to_Collect')}} lists some jsunit examples.
</li><li> Refer to documentation on {{mediawiki.interwiki('wikimo', 'SoftwareTesting:Tools:jsUnit', 'wikimo:SoftwareTesting:Tools:jsUnit')}} for more information.
</li><li> Some <a class="external" href="http://beaufour.dk/xftst/">XForms tests</a> uses JsUnit, as an example
</li></ul>
</li></ul>
<h3 name="Existing_Test_Harnesses_and_Frameworks"> Existing Test Harnesses and Frameworks </h3>
<p>(originally from {{mediawiki.interwiki('wikimo', 'SoftwareTesting:Catalog_of_Automated_Tests', 'wikimo:SoftwareTesting:Catalog_of_Automated_Tests')}})
</p>
<ul><li> <a class="external" href="http://wiki.mozilla.org/Performance:Tinderbox_Tests">Tinderbox performance tests</a>
</li><li> <a class="external" href="http://lxr.mozilla.org/mozilla/source/browser/components/places/tests/">Places test script</a>
</li><li> <a class="external" href="http://lxr.mozilla.org/mozilla/source/netwerk/test/unit/">Netwerk unit tests</a>
</li><li> <a class="external" href="http://lxr.mozilla.org/mozilla/source/js/tests/">javascript tests</a>
</li><li> <a class="external" href="http://lxr.mozilla.org/mozilla/source/security/nss/tests/">nss tests</a>
</li><li> <a class="external" href="http://landfill.mozilla.org/mxr-test/mozilla/source/nsprpub/pr/tests/">nspr tests</a>
</li><li> <a class="external" href="http://www.mozilla.org/newlayout/doc/regression_tests.html">layout tests - diff of frame tree dump against golden master</a>
</li><li> <a class="external" href="https://bugzilla.mozilla.org/show_bug.cgi?id=301260">bz's copy of netwerk tests for xmlserializer</a>
</li><li> <a class="external" href="http://www.w3.org/DOM/Test/">W3C DOM Tests</a> uses <a class="external" href="http://www.edwardh.com/jsunit/">jsunit</a>
</li><li> <a class="external" href="http://wiki.mozilla.org/XSLT_Tests">XSLT Tests</a>
</li><li> http://hixie.ch/tests/MANIFEST all hixie's tests
</li><li> http://hixie.ch/tests/MANIFEST-visual subset of hixie's tests that is non-interactive
</li><li> <a class="external" href="http://www.allpeers.com/blog/2005/09/28/foxunit-unit-test-framework-for-firefox/">FoxUnit</a> - jUnit-like harness for Firefox, by the AllPeers folks
</li></ul>
Revertir a esta revisión