Closed Bug 696295 Opened 13 years ago Closed 11 years ago

Tracking: Add qemu tests for hardware APIs once the harness is ready

Categories

(Core :: DOM: Core & HTML, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
blocking-basecamp -

People

(Reporter: cjones, Unassigned)

References

Details

We need to land some new DOM APIs that we can't test properly and automatically without better harness support.  Those will land with Litmus and basic API tests, but once the harness support is there, we need to add comprehensive functional tests.  Tracking them here so that we don't forget.
Is there someplace I can look to see what it is in mind that you need for better harness support?  We are currently building some harness support for b2g, which is the ultimate consumer of these APIs and so I want to be sure that we're planning and thinking about the right things.
The most that's been written up is [1].  Briefly, we want to launch qemu instances, manipulate them using something like the console interface [2], and also check for specific output that might be spewed from something like the console.

Running tests within qemu instances should work the same as running them using adb on real devices, since adb knows about running android-qemu instances.  We'll want to launch multiple instances to test APIs like SMS and telephony, which may require new code.  We'll need some new code in the harnesses to frob the virtual devices.  We'll also need some new code in qemu to support virtual devices better.  The good news is that qemu runs on desktops (obviously) so it's a lot easier to hack on.

What's the best place for us to discuss this work?  Here ok?

[1] http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/dae263e27197f9a0#
[2] http://developer.android.com/guide/developing/devices/emulator.html#console
Oh, and I forgot to add: running in the harness the code shown as

     <!-- Runs in test driver -->
     <script type="application/python">

in the example will obviously also require new harness code.
One more thing: we'll want to use all this new harness code for Firefox/Android too, to test the APIs we're able to add there.  We won't be able to run the "receive call" tests, e.g., because we can't implement that feature on android.
Depends on: 702671
Not actually blocking each of those APIs (some of which have landed). Having a testing tracker bug muddies the water. If there are specific features that need tests that we can't ship without, file individual bugs for those.
No longer blocks: websms, webtelephony, 678694, 679966
blocking-basecamp: --- → -
We are indeed adding these tests.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.