summaryrefslogtreecommitdiffstats
path: root/testing/mozbase/docs/mozrunner.rst
diff options
context:
space:
mode:
authorMatt A. Tobin <mattatobin@localhost.localdomain>2018-02-02 04:16:08 -0500
committerMatt A. Tobin <mattatobin@localhost.localdomain>2018-02-02 04:16:08 -0500
commit5f8de423f190bbb79a62f804151bc24824fa32d8 (patch)
tree10027f336435511475e392454359edea8e25895d /testing/mozbase/docs/mozrunner.rst
parent49ee0794b5d912db1f95dce6eb52d781dc210db5 (diff)
downloadUXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar
UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.gz
UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.lz
UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.xz
UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.zip
Add m-esr52 at 52.6.0
Diffstat (limited to 'testing/mozbase/docs/mozrunner.rst')
-rw-r--r--testing/mozbase/docs/mozrunner.rst177
1 files changed, 177 insertions, 0 deletions
diff --git a/testing/mozbase/docs/mozrunner.rst b/testing/mozbase/docs/mozrunner.rst
new file mode 100644
index 000000000..766b02cc4
--- /dev/null
+++ b/testing/mozbase/docs/mozrunner.rst
@@ -0,0 +1,177 @@
+:mod:`mozrunner` --- Manage remote and local gecko processes
+============================================================
+
+Mozrunner provides an API to manage a gecko-based application with an
+arbitrary configuration profile. It currently supports local desktop
+binaries such as Firefox and Thunderbird, as well as Firefox OS on
+mobile devices and emulators.
+
+
+Basic usage
+-----------
+
+The simplest way to use mozrunner, is to instantiate a runner, start it
+and then wait for it to finish:
+
+.. code-block:: python
+
+ from mozrunner import FirefoxRunner
+ binary = 'path/to/firefox/binary'
+ runner = FirefoxRunner(binary=binary)
+ runner.start()
+ runner.wait()
+
+This automatically creates and uses a default mozprofile object. If you
+wish to use a specialized or pre-existing profile, you can create a
+:doc:`mozprofile <mozprofile>` object and pass it in:
+
+.. code-block:: python
+
+ from mozprofile import FirefoxProfile
+ from mozrunner import FirefoxRunner
+ import os
+
+ binary = 'path/to/firefox/binary'
+ profile_path = 'path/to/profile'
+ if os.path.exists(profile_path):
+ profile = FirefoxProfile.clone(path_from=profile_path)
+ else:
+ profile = FirefoxProfile(profile=profile_path)
+ runner = FirefoxRunner(binary=binary, profile=profile)
+ runner.start()
+ runner.wait()
+
+
+Handling output
+---------------
+
+By default, mozrunner dumps the output of the gecko process to standard output.
+It is possible to add arbitrary output handlers by passing them in via the
+`process_args` argument. Be careful, passing in a handler overrides the default
+behaviour. So if you want to use a handler in addition to dumping to stdout, you
+need to specify that explicitly. For example:
+
+.. code-block:: python
+
+ from mozrunner import FirefoxRunner
+
+ def handle_output_line(line):
+ do_something(line)
+
+ binary = 'path/to/firefox/binary'
+ process_args = { 'stream': sys.stdout,
+ 'processOutputLine': [handle_output_line] }
+ runner = FirefoxRunner(binary=binary, process_args=process_args)
+
+Mozrunner uses :doc:`mozprocess <mozprocess>` to manage the underlying gecko
+process and handle output. See the :doc:`mozprocess documentation <mozprocess>`
+for all available arguments accepted by `process_args`.
+
+
+Handling timeouts
+-----------------
+
+Sometimes gecko can hang, or maybe it is just taking too long. To handle this case you
+may want to set a timeout. Mozrunner has two kinds of timeouts, the
+traditional `timeout`, and the `outputTimeout`. These get passed into the
+`runner.start()` method. Setting `timeout` will cause gecko to be killed after
+the specified number of seconds, no matter what. Setting `outputTimeout` will cause
+gecko to be killed after the specified number of seconds with no output. In both
+cases the process handler's `onTimeout` callbacks will be triggered.
+
+.. code-block:: python
+
+ from mozrunner import FirefoxRunner
+
+ def on_timeout():
+ print('timed out after 10 seconds with no output!')
+
+ binary = 'path/to/firefox/binary'
+ process_args = { 'onTimeout': on_timeout }
+ runner = FirefoxRunner(binary=binary, process_args=process_args)
+ runner.start(outputTimeout=10)
+ runner.wait()
+
+The `runner.wait()` method also accepts a timeout argument. But unlike the arguments
+to `runner.start()`, this one simply returns from the wait call and does not kill the
+gecko process.
+
+.. code-block:: python
+
+ runner.start(timeout=100)
+
+ waiting = 0
+ while runner.wait(timeout=1) is None:
+ waiting += 1
+ print("Been waiting for %d seconds so far.." % waiting)
+ assert waiting <= 100
+
+
+Using a device runner
+---------------------
+
+The previous examples used a GeckoRuntimeRunner. If you want to control a
+gecko process on a remote device, you need to use a DeviceRunner. The api is
+nearly identical except you don't pass in a binary, instead you create a device
+object. For example, for B2G (Firefox OS) emulators you might do:
+
+.. code-block:: python
+
+ from mozrunner import B2GEmulatorRunner
+
+ b2g_home = 'path/to/B2G'
+ runner = B2GEmulatorRunner(arch='arm', b2g_home=b2g_home)
+ runner.start()
+ runner.wait()
+
+Device runners have a `device` object. Remember that the gecko process runs on
+the device. In the case of the emulator, it is possible to start the
+device independently of the gecko process.
+
+.. code-block:: python
+
+ runner.device.start() # launches the emulator (which also launches gecko)
+ runner.start() # stops the gecko process, installs the profile, restarts the gecko process
+
+
+Runner API Documentation
+------------------------
+
+Application Runners
+~~~~~~~~~~~~~~~~~~~
+.. automodule:: mozrunner.runners
+ :members:
+
+BaseRunner
+~~~~~~~~~~
+.. autoclass:: mozrunner.base.BaseRunner
+ :members:
+
+GeckoRuntimeRunner
+~~~~~~~~~~~~~~~~~~
+.. autoclass:: mozrunner.base.GeckoRuntimeRunner
+ :show-inheritance:
+ :members:
+
+DeviceRunner
+~~~~~~~~~~~~
+.. autoclass:: mozrunner.base.DeviceRunner
+ :show-inheritance:
+ :members:
+
+Device API Documentation
+------------------------
+
+Generally using the device classes directly shouldn't be required, but in some
+cases it may be desirable.
+
+Device
+~~~~~~
+.. autoclass:: mozrunner.devices.Device
+ :members:
+
+Emulator
+~~~~~~~~
+.. autoclass:: mozrunner.devices.Emulator
+ :show-inheritance:
+ :members: