WebDriver/Marionette

Note: This page is subject to change since Marionette is still being fleshed out.

See also https://wiki.mozilla.org/Platform/JSDebugv2

Problem

We need a new and unified way to be able to automate testing remotely on the B2G environment since we won't have the traditional browser environment to hook onto as we have done in the past, since we'll be booting directly into Gecko and will have to test functionality of the UI. We'll want to be able to test anything the user can do, from entering input, to gestures, etc.

Goals

• We want to be able to send remote testing commands to the mobile device. We do not want to hardcode what kind of test actions are available, we want this to be a unified method of sending commands to the phone, and then having a dispatcher on the mobile side sending the commands to the appropriate listener or harness. This would make this solution robust and able to handle any other test harnesses the future may hold.

• The test actions requested should be in JSON form both for simplicity and eventual support of Selenium / WebDriver commands. Selenium/WebDriver support would entice more developers to write tests due to its popularity and potential as a testing standard.

• If we integrate with remote-debugger, we will be able to send both debugging commands and testing commands over the same socket connection.

• In the first pass, we want to be able to support Eideticker on the remote device, so we should focus support for this project.

Design and Implementation

Note: The current design grew from the ideas presented here. We selected approach#3.

In order to send the JSON commands to the mobile device, we will use the already written socket listener/debugger, remote-debugger. We can integrate our command dispatcher to the remote-debugger in the form of an Actor. This will allow us to connect to the socket and send debug or testing commands by addressing the JSON messages to the appropriate actor. The remote-debugger code is subject to change as it is not yet part of mozilla-central, so the design may change if anything radical happens.

We will have to write our own root actor that will start at Gecko launch. This root actor can then register any number of actors below it. This would allow us to add debugging as well as testing actors. Since the debugging actors currently available are all browser-specific, we may not have any debuggers for Gecko available when Marionette first comes out.

Once the testing actor receives the testing command, it will dispatch it to the appropriate test harness or listener. For now, we plan to use the accessibility (a11y) interfaces that is already supported by the platform. For actions not covered by a11y, like gestures, we should be able to fire off events directly to the mobile device's event queue.

Development

Tracking Progress

We're currently tracking our progress with Pivotal Tracker. More stories to come.

Notes

notes

Questions/Comments/Concerns

Feel free to drop me (mdas) a line over at the #ateam channel, or email me via mdas [at ] mozilla . com