We need to have some test case for mediaRecorder.

Testing cases 1. record/ stop i. record with defined timeslice ii. record with out timeslice(client side need to call requestData manually) Pass criteria i. Check recording status ii. Check ondataavalaible 2. pause/ resume Pass criteria i. Check recording status ii. Check ondataavalaible Unclear item, need more discussion 1. How to create test case for onerror and onwarning? Do we need that? 2. Do we need to have onpause/ onresume test case? Currently, the implementation of MediaRecorder.pause and MediaRecorder.resume is sync.

(In reply to C.J. Ku[:CJKu] from comment #2) > Testing cases > 1. record/ stop > i. record with defined timeslice > ii. record with out timeslice(client side need to call requestData > manually) > Pass criteria > i. Check recording status > ii. Check ondataavalaible > 2. pause/ resume > Pass criteria > i. Check recording status > ii. Check ondataavalaible > > Unclear item, need more discussion > 1. How to create test case for onerror and onwarning? Do we need that? > 2. Do we need to have onpause/ onresume test case? Currently, the > implementation of MediaRecorder.pause and MediaRecorder.resume is sync. FYI: http://w3c.github.io/testing-how-to/ provides some guidelines for testing web API. test code repo: https://github.com/w3c/web-platform-tests

We have some modules that already use W3C-style tests, integrating them into our build and test system. See for example dom/encoding/test.

Also need to test the pause/resume API.

This should not be blocker for release. Test case is for the quality enhancement from developer.

(In reply to Ivan Tsay (:ITsay) from comment #6) > This should not be blocker for release. Test case is for the quality > enhancement from developer. For any user story to be deemed as done, unit/integration automation has been made a requirement by the other sprint teams for each user story. This is done to remove past historical problems such as uncontrolled regression rates that have occurred due to a lack of focus of test automation. As such, the sprint criteria of the media recording team should be following the same criteria here. I would strongly caution treating this as an enhancement - per the recent Oslo work week priority discussions, this is a priority of 1.2 and should be slotted for a sprint along with the media encoder native test cases. Otherwise, we'll just repeat past historical mistakes we've done on past Firefox OS releases.

I don't think it's a blocker for release though, however. But my point in comment 7 is that you still need to get this done to really call your user stories complete per similar acceptance criteria with other sprint teams.

Here's a better idea - I'm going to make this a tracker bug for mochitests and remove the blocking nom.

Let the metabug just for tracking.

So this suite is theoretically running on Cedar now, but the first test is timing out: https://tbpl.mozilla.org/php/getParsedLog.php?id=36205115&tree=Cedar&full=1 I don't know if this is coincidence or if there is something wrong with the harness. Maybe re-factoring these tests into a separate directory would be helpful. Or we could figure out how to separate emulator-jb from emulator-ics in the manifests (which we should probably do anyway). I'll try disabling the failing test to see if it's a harness problem or not.

Sigh, no there seems to be some deeper issue. I'll file another bug. FTR the media tests work on emulator-jb for me locally.