Development of an extensive test suite to verify the functionality of the first group of Firefox OS WebAPIs is underway. Ultimately the test suite will run on the B2G device emulator on a per-check-in basis.
To develop a WebAPI test which will run on the B2G device emulator, which automation framework is best suited for the task: Mochitest or Marionette? This blog post will help answer that question, and provide some useful emulator tips.
The Mochitest automation framework has access to gecko and the WebAPIs but cannot access the lower-level emulated ‘hardware’ features and commands that are offered in the B2G emulator. The Marionette automation framework can access both the WebAPIs and the emulated ‘hardware’ and associated emulator commands. Therefore, if the WebAPI test under development requires direct access to the emulated hardware support and special emulator functions, then Marionette should be used; otherwise Mochitest is sufficient for the task.
For example, if you are developing a new WebAPI test for the ContactsAPI, Mochitest is the best choice as no special emulated hardware access or functions is required to test Contacts. However, if you are developing a WebAPI test for the WebTelephony API, Marionette is the automation framework of choice because the B2G device emulator has special commands that allow the partial-simulation of phone calls.
The B2G device emulator offers console commands that can help emulate specific hardware features, and therefore be used to verify some of the WebAPIs. To see a list of commands (or to try out some of them yourself) start-up the B2G device emulator, then open a terminal window and connect to the emulator’s android console via telnet:
$ telnet localhost 5554
Where ’5554′ is the default emulator port (displayed on the emulator window title). Once connected to the emulator’s android console, simply type ‘help’ to see a list of available commands. As an example, to use the emulator to simulate an incoming phone call, issue the following command in the android emulator console:
gsm call 5551112222
Where ’5551112222′ is the phone number of the simulated remote mobile from which the incoming call is originated. Once the above command is issued, notice that the emulator gui (gaia) indicates that there is an incoming call from the specified number. The simulated call can then be answered or rejected using more emulator console commands (or via the gaia interface itself).
To send a console command to the emulator from within a WebAPI test, Marionette provides the ‘runEmulatorCmd’ function. For example, to simulate an incoming call on the emulator use the following js code in your WebAPI test:
let inNumber = “5551112222″;
runEmulatorCmd(“gsm call ” + inNumber);
As an optional argument to ‘runEmulatorCmd’, a callback function can be provided which will be invoked after the emulator processes the command, and the emulator console output will be provided. For example:
runEmulatorCmd(“gsm list”, function(result) {
log(“Current call list: ” + result);
});
The ‘gsm list’ command asks the emulator to output a list of currently simulated phone calls and their status. In the above example the resulting console output of the command (list of simulated calls, or just ‘ok’ if no calls exist) is provided to the callback function. For more information see Marionette JavaScript Tests in MDN.
Additional information about the Automation Development team’s efforts to help with WebAPI test development can be found on our team’s projects wiki. If you are interested in contributing please contact me or find us in the #automation room on IRC.
(Thanks JGriffin and MDas for answering my various questions on these subjects.)
