WebDriver/Marionette: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
__TOC__ | __TOC__ | ||
Note: This page is subject to change since Marionette is still being fleshed out. | |||
= 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. | 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. | *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. | ||
| Line 13: | Line 14: | ||
*If we integrate with [https://wiki.mozilla.org/Platform/JSDebugv2 remote-debugger], we will be able to send both debugging commands and testing commands over the same socket connection. | *If we integrate with [https://wiki.mozilla.org/Platform/JSDebugv2 remote-debugger], we will be able to send both debugging commands and testing commands over the same socket connection. | ||
= Design and Implementation = | |||
The [https://wiki.mozilla.org/Platform/JSDebugv2 remote-debugger] is a means of sending remote debugging commands over a socket connection. We can integrate our command dispatcher to the remote-debugger in the form of an [https://wiki.mozilla.org/Remote_Debugging_Protocol#Actors Actor]. This will allow us to connect to the socket and send debug commands to the remote-debugger specific actors, or send our testing commands to our testing actor. | The [https://wiki.mozilla.org/Platform/JSDebugv2 remote-debugger] is a means of sending remote debugging commands over a socket connection. We can integrate our command dispatcher to the remote-debugger in the form of an [https://wiki.mozilla.org/Remote_Debugging_Protocol#Actors Actor]. This will allow us to connect to the socket and send debug commands to the remote-debugger specific actors, or send our testing commands to our testing actor. | ||
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 [https://developer.mozilla.org/en/nsIAccessible 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. | 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 [https://developer.mozilla.org/en/nsIAccessible 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. | ||
Revision as of 20:15, 5 October 2011
Note: This page is subject to change since Marionette is still being fleshed out.
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.
Design and Implementation
The remote-debugger is a means of sending remote debugging commands over a socket connection. 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 commands to the remote-debugger specific actors, or send our testing commands to our testing actor.
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.