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 . Briefly, we want to launch qemu instances, manipulate them using something like the console interface , 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?
Oh, and I forgot to add: running in the harness the code shown as
<!-- Runs in test driver -->
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.
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.
We are indeed adding these tests.