|
|
| Line 7: |
Line 7: |
|
| |
|
| These calls work on desktop Firefox. B2G has support for all but navigation calls (goBack, goUrl, etc.). Birch/Mobile support has yet to be added. | | These calls work on desktop Firefox. B2G has support for all but navigation calls (goBack, goUrl, etc.). Birch/Mobile support has yet to be added. |
|
| |
| === Bugs ===
| |
|
| |
| You can track our [https://bugzilla.mozilla.org/buglist.cgi?product=Testing&component=Marionette&resolution=---&list_id=1844713 bugs], and see which bugs are being worked on over at our [https://www.pivotaltracker.com/projects/387361 pivotal tracker].
| |
|
| |
| === Unit tests ===
| |
| ==== Running the XPCShell Tests ====
| |
| Marionette has [https://developer.mozilla.org/en/XPConnect/xpcshell xpcshell] tests.
| |
|
| |
| You will need to run `make stage-xpcshell` from the $(OBJDIR). Then, from $(OBJDIR)/dist/test-package-stage/xpcshell you can run: python runxpcshelltests.py --xre-path=../../bin ../../bin/xpcshell tests/toolkit/devtools/marionette/tests/unit/ --test-path=test_marionette.js --logfiles
| |
|
| |
| The test should pass.
| |
|
| |
| ==== Running the Marionette Client tests ====
| |
| If you're testing with a running application with marionette running on <host>:<port>, then after getting the marionette client code, navigate to the marionette directory and run the following to test unit tests:
| |
| python runtests.py --address <host>:<port> tests/unit
| |
|
| |
| If you want to run with an emulator (with B2G), define the B2G_HOME environment variable so it points to the top of the B2G tree, and then run the following for both emulation and unit tests:
| |
| python runtests.py --emulator tests
| |
|
| |
| in both cases 'tests' refers to the tests directory that is within the marionette directory
| |
|
| |
| == Marionette & Eideticker integration ==
| |
| Marionette should support two Eideticker tests:
| |
| * start the browser and load a page
| |
| * start the browser, do some interaction (click and type), close browser
| |
|
| |
| It should be able to respond to json wire protocol commands that would allow these two tests to complete. Eideticker will no longer need to use JSBridge or its own firefox extension once Marionette has support for these actions.
| |
|
| |
| Initially, we will be allowing an [http://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/execute execute] script call to come into Marionette. It will execute a blob of Javascript and return the script results Following this, we will allow an [http://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/execute_async execute asynchronous] call so that we can support events that require waiting (page load, etc.).
| |
|
| |
| == Questions ==
| |
| * How will we turn Marionette on and off? Via a pref?
| |
| * How does will the browser work in B2G, how does it behave? Is it the same Fennec or is it different?
| |
| ** Exactly the same fennec code, only it is started when you bring up the browser. As yet, the codebase is unforked in this capacity, and the drive is to not fork the gecko platform between "normal" fennec and the fennec layer running on B2G
| |
| * What is the difference between chrome and content in terms of dispatching actions to either group?
| |
| ** You can see the difference in dispatching a script call by looking at what the scratchpad does - alternately execute in chrome or content depending on what the user has selected on a menu:
| |
| *** http://mxr.mozilla.org/mozilla-central/source/browser/devtools/scratchpad/scratchpad.js#332
| |
| For dispatching "events" we will use message managers to dispatch into content (you're coming from chrome). Dispatching for chrome is easy since you're already in chrome.
| |
| * What is the B2G UI environment? XUL, HTML5? How does a11y interface handle them?
| |
| ** HTML5. that's the point of B2G. A11y will have to handle it, and may have to have capabilities developed in parallel. that's why we're working with dbolter.
| |
| * Do we need to worry about a11y in a multiprocess environment (ie: can we dispatch a11y commands to both chrome and content?)
| |
| ** No, a11y by definition has to be able to do this. We will hopefully be able to let the a11y subsystem handle it.
| |
|
| |
| == Emulation ==
| |
|
| |
| === Running B2G and Marionette on an emulator ===
| |
|
| |
| To run B2G with Marionette on an emulator, setup all the B2G pre-requisites (sans attaching your device) at https://github.com/jonallengriffin/B2G/blob/master/INSTALL. Then run these commands:
| |
|
| |
| git clone git://github.com/jonallengriffin/B2G.git
| |
| cd B2G
| |
| make sync
| |
| make config-qemu
| |
| make gonk
| |
| make
| |
| ./emu.sh
| |
|
| |
| Note you'll need to use the Android backend at present; the B2G backend is not supported on anything except the Galaxy S2.
| |
|
| |
| To test this code with the Python client, do this:
| |
|
| |
| git clone git://github.com/jonallengriffin/marionette_client.git
| |
| cd marionette_client/marionette
| |
| python runtests.py --emulator --homedir=/path/to/b2g_repo tests/unit-tests-b2g.ini
| |
|
| |
| This should launch an emulator and run a series of unit tests on it to verify Marionette is working correctly.
| |
|
| |
| ==== Using a running emulator ====
| |
| If you are already running an emulator, you can still run these tests. To do so, please remember to forward the port:
| |
| adb forward tcp:2828 tcp:2828
| |
|
| |
| Then you can run the tests:
| |
| python runtests.py --emulator --homedir=/path/to/b2g_repo --address localhost:2828 tests/unit-tests-b2g.ini
| |
|
| |
| The --emulator and --homedir paramaters are required to notify the testrunner to run in 'emulator' mode and tells it where to find particular programs it needs (adb). The using the --address parameter tells it that an emulator is already running (so it won't start one up for you), and then uses the address you pass it to talk to it.
| |
|
| |
| === Debugging the emulator ===
| |
|
| |
| It's a big PITA to debug things on the emulator. I've added some logging code (inspired by ctalbert) which you can use to write things to a log file. To use it, you can do this from JS code:
| |
|
| |
| Cu.import("resource:///modules/marionette-logger.jsm");
| |
| MarionetteLogger.write('some message');
| |
|
| |
| To view the log, do this, while the emulator is running:
| |
|
| |
| $B2G_HOME/glue/gonk/out/host/linux-x86/bin/adb shell cat /data/data/org.mozilla.b2g_$USER/marionette.log
| |
|
| |
| where $USER is the value of the USER env variable on your host machine. If 'marionette-log' already exists when the emulator is launched, a marionette-1.log will be created, and so forth.
| |
|
| |
| ==Running Marionette on Desktop Firefox ==
| |
|
| |
| To run Marionette in Firefox, make sure you have the environment ready for [https://developer.mozilla.org/en/Build_Documentation building firefox]. Once you're at the stage of configuring and building firefox, you can follow these steps:
| |
|
| |
| At the top of your mozilla-central tree, create an hg patch queue:
| |
| hg qinit
| |
|
| |
| Navigate to $(m-c)/.hg/patches and clone the [http://hg.mozilla.org/users/mdas_mozilla.com/marionette-pq marionette code]
| |
|
| |
| cd $(m-c)/.hg/patches
| |
| hg clone http://hg.mozilla.org/users/mdas_mozilla.com/marionette-pq .
| |
|
| |
| Replace the 'series' file with the 'series-add-rd' file (Note for the curious: the 'series' file that is included in the repo is for patching the remote-debug branch of m-c, not for m-c actual):
| |
|
| |
| cp series-add-rd series
| |
|
| |
| and then apply all the patches to m-c:
| |
|
| |
| cd ../../
| |
| hg qpush -a
| |
|
| |
| Once all the patches are successfully applied, you may now configure and build:
| |
|
| |
| make -f client.mk config
| |
| make -f client.mk build
| |
|
| |
| The Firefox build in your object-directory now has Marionette installed. If you launch it, then Marionette will be listening on localhost:2828.
| |
|
| |
|
| == Components == | | == Components == |