Search completed in 1.42 seconds.
Metro browser chrome tests - Archive of obsolete content
it currently allows you to run javascript code in the same scope as the immersive browser and report results using the same functions as the
mochitest test framework.
... running the metro browser chrome tests to run
mochitest, first build mozilla with your changes; then run ./mach
mochitest-metro this will launch metro browser chrome tests in the default immersive browser.
...as with
mochitest, the path given as an argument is the path to a test file within the mozilla source tree.
...And 4 more matches
Browser chrome tests
it currently allows you to run javascript code in the same scope as the main firefox browser window and report results using the same functions as the
mochitest test framework.
... running the browser chrome tests to run
mochitest, first build mozilla with your changes; then run ./mach
mochitest -f browser this will launch your build and open a "browser chrome tests" window, and report the results in the ui and to stdout.
...as with
mochitest, the path given as an argument is the path to a test or directory within the mozilla source tree.
...And 4 more matches
Creating reftest-based unit tests
, go to the directory where you save firefox's source code and run: ./mach reftest if you want to run a particular set of reftests, pass the path as an argument: ./mach reftest path/from/sourcedir/reftest.list and to run a single reftest just pass the path to the test file (not the reference file): ./mach reftest path/from/sourcedir/reftest-name.html there is no reftest equivalent to mach
mochitest --keep-open, but temporarily adding the reftest-wait class to a test (or disabling the script that removes it) will keep it open longer.
...you can accomplish this by either: rewrite them as
mochitests.
... the helper functions snapshotwindow and comparesnapshots are available in testing/
mochitest/tests/simpletest/windowsnapshot.js.
Testing the Add-on SDK - Archive of obsolete content
with mach there are two commands: ./mach
mochitest -f jetpack-addon <optional_addon_path>: this runs the test add-ons mentioned for cfx testaddons and gulp test:addons with the older sdk/loader/cuddlefish used with cfx.
... ./mach
mochitest -f jetpack-package <optional_file_path>: this runs the module unit tests mentioned for cfx testpkgs and gulp test:modules but in this case with the newer toolkit/loader used with jpm.
Adding a new CSS property
this will cause tests of your new property to be added to many of the
mochitests in layout/style/test, which can be run with the command "./mach
mochitest -f plain layout/style/".
... finishing up then you'll need to rebuild and run the
mochitests in layout/style (./mach
mochitest -f plain layout/style/).
mach
if it works, you can look at compiler warnings: $ ./mach warnings-list try running the program: $ ./mach run try running your program in a debugger: $ ./mach run --debug try running some tests: $ ./mach xpcshell-test services/common/tests/unit/ or run an individual test: $ ./mach
mochitest browser/base/content/test/general/browser_pinnedtabs.js you run mach from the source directory, so you should be able to use your shell's tab completion to tab-complete paths to tests.
... for example: $ cd devtools/client $ mach build webconsole # rebuild only the files in the devtools/client/webconsole directory $ mach
mochitest webconsole/test # run
mochitests in devtools/client/webconsole/test enable tab completion to enable tab completion in bash, run the following command.
Index - Archive of obsolete content
it currently allows you to run javascript code in the same scope as the immersive browser and report results using the same functions as the
mochitest test framework.
Debugging
replay debugging firefox with vmware workstation how to setup record and replay debugging on firefox, to help debug intermittent
mochitest failures.
pymake
to run tests instead of typing make
mochitest-plain in the object directory, you would type python ../build/pymake/make.py
mochitest-plain.
ESLint
ensure there is a .eslintrc.js file that extends one of: "plugin:mozilla/browser-test" "plugin:mozilla/chrome-test" "plugin:mozilla/
mochitest-test" "plugin:mozilla/xpcshell-test" see other test directories for how to do this.
How test harnesses work
tdestiny) potentially sets up an http server for test data (mozhttpd) invokes the binary (mozrunner) it is the job of the shim extension to shut down the browser logging (mozlog, in theory) (run tests, accrue results) cleanup: shutdown the browser check for crashes (mozcrash) reporting (moztest) marionette tests list of testing extensions pageloader (talos)
mochitest: //github.com/realityripple/uxp/blob/master/testing/
mochitest/install.rdf (
mochitest) ...
Creating a New Protocol
writing the tests protocols which are managed by pbrowser must be tested using the
mochitest-chrome test framework with a <browser remote="true">.
Assert.jsm
this report method only throws errors on assertion failures, as per spec, but consumers of this module (think: xpcshell-test,
mochitest) may want to override this default implementation.
BloatView
to do so, the xpcom_mem_log_classes environment variable should be set to the name of the class from the bloatview table: xpcom_mem_log_classes=myclass mach
mochitest [options] multiple class names can be specified by setting xpcom_mem_log_classes to a comma-separated list of names: xpcom_mem_log_classes=myclass,myotherclass,deliberatelyleakedclass mach
mochitest [options] test harness scripts typically accept a --setenv option for specifying environment variables, which may be more convenient in some cases: mach
mochitest --setenv=xpcom_mem_log_classes=my...
NSPR LOG MODULES
set nspr_log_modules=timestamp,mozstorage:5 set nspr_log_file=/tmp/foo.log logging with try server for
mochitest, edit variable nspr_log_modules in testing/
mochitest/runtests.py before pushing to try.
Creating JavaScript jstest reftests
if your test needs to use browser-specific features, either: make the test silently pass if those features aren't present; or write a
mochitest instead (preferred); or at the top of the test, add the comment // skip-if(xulruntime.shell), so that it only runs in the browser.
WebIDL bindings
note that if you're adding new interfaces, then the test at dom/tests/
mochitest/general/test_interfaces.html will most likely fail.
Mozilla
it currently allows you to run javascript code in the same scope as the main firefox browser window and report results using the same functions as the
mochitest test framework.
Online and offline events - Web APIs
ventlistener('online', updateonlinestatus); window.addeventlistener('offline', updateonlinestatus); }); a touch of css #status { position: fixed; width: 100%; font: bold 1em sans-serif; color: #fff; padding: 0.5em; } #log { padding: 2.5em 0.5em 0.5em; font: 1em sans-serif; } .online { background: green; } .offline { background: red; } and the corresponding htmlxxx when
mochitests for this are created, point to those instead and update this example -nickolay <div id="status"></div> <div id="log"></div> <p>this is a test</p> here's the live result notes if the api isn't implemented in the browser, you can use other signals to detect if you are offline including using service workers and responses from xmlhttprequest.