Tim, FYI, I introduced an API for mochitest-plain for these kind of shortcomings. It is now being used by various b2g-related tests. https://bugzilla.mozilla.org/show_bug.cgi?id=914633
http://mxr.mozilla.org/mozilla-central/search?string=loadChromeScript&find=&findi=&filter= ^[^\0]*%24&hitlimit=&tree=mozilla-central SpecialPowers.loadChromeScript() and a message manager like API. It allows you to easily execute some code in the parent process/chrome from the mochitest-plain, which is child/content only. It was an easy way to write some tests that looks like mochitest-chrome from the mochitest-plain runner (which is the only mochitests being run on b2g). But I can easily agree on the fact that we are lacking a chrome test harness on b2g being run from mozilla-central, and, ideally, using a gaia profile. Devtools team started introducing tests in gaia integration tests because of that, but we stopped doing that as we were introducing tests against mozilla-central codebase within gaia repo... Existing devtools tests within gaia: https://github.com/mozilla-b2g/gaia/tree/master/tests/integration/devtools New tests that have been rejected by gaia owners, that highlights how easy it would be to introduce a new test harness via gaia marionette: https://github.com/mozilla-b2g/gaia/pull/21498/files See the discussion from here: https://bugzilla.mozilla.org/show_bug.cgi?id=1025828#c15 ++ Alex 2014-11-04 8:28 GMT+01:00 Tim Chien <[email protected]>: > On Tue, Nov 4, 2014 at 3:20 PM, Tim Chien <[email protected]> wrote: > > td; lr, I am looking for a way to set up correct tests for oop > > mozbrowser and input method API and all current test frameworks have > > some shortcoming preventing me to do so. I propose we should either > > fix them or introduce a new way to run tests. > > > > Hi all, > > > > I have two patches related to Rocketbar which I am unable to create a > > valid test for. They are about ipc ordering of Input Method API > > internal so I can't create valid tests unless I can put one input box > > in the chrome process and another in child process. > > > > The first place I was looking at is creating oop frames in Fx desktop > > mochitests, since that's where the test is being run at the moment. > > mozbrowser mochitests are indeed running on oop mozbrowser iframes too > > so it should be available, but it turned out it only works to a > > certain point: > > > > * The remote frames has no rendering [1] > > * The remote frames can't properly receive any focus [2] > > > > The [2] in particular prevent me to write oop Input Method API tests > > on Fx desktop mochitests. So I am blocked. > > > > I therefore begin to look at other test suites. Gaia integration tests > > would work, however these tests would be Gaia UI dependent and the API > > codebase will lost the protection when the UI changes in the future. > > Also, Gij is hidden and being work on for [3]. > > > > I thought about mochitests in Emulator. However, according to [4] the > > mochitest page will be run in child process (as "home screen" of the > > phone). It's not possible to test oop behavior (or mixed oop/inproc) > > under this setup. Evidently, oop mozbrowser mochitests are all > > disabled on emulator, inproc tests too if not all. > > > > With all options depleted, this post is a cry for help. What I think > > we should do is to (a) bump [1][2] and get them fixed so we could rely > > on Fx Desktop to test these APIs to a certain point. Or, (b) > > alternatively, instead of have the test container app replacing home > > screen as described in [4], we should allow mochitest frame being > > loaded as System app in the chrome process. > > > > Thoughts? > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1085217 > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1090032 > > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=960072 > > [4] > https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Mochitests#Technical_Implementation_Details > > > > Small correction, the test container app is actually replacing the > System app, not the Homescreen app. > The terminology in [4] is outdated. > > > http://dxr.mozilla.org/mozilla-central/source/testing/profiles/prefs_b2g_unittest.js#3-4 > > What I am talking about in (b) is to be able to run mochitests _not_ > in the <iframe mozbrowser remote> of that app, but replace the test > container app page itself. > > -- > Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox > OS, Mozilla Corp. (Taiwan) > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
