I am more worry about Gecko - Gaia System interaction. Gecko currently just "happen" to work with Gaia System app under our use cases with it's mozbrowserloadstart/DOMContentLoaded/mozbrowserloadend/load events happens on the right time, with Gaia System send back mozContentEvent on the right time.
-- what if we are on a extremely fast phone or slow phone (in terms of parsing speed and/or disk load speed)? -- what if everything in Gaia System is lazily loaded so the events happen in different timing or sequences? -- what if B2G runtime is configured to load a page from localhost or even remote network, so it's load speed cannot be certained? They sounds like hypothesis, but without these tests in the suite, we probably cannot do any heavy lifting in System app without realizing we break something. Thanks. On Tue, Oct 29, 2013 at 11:56 PM, Jonathan Griffin <[email protected]> wrote: > Do the tests you need to write need to interact with the gaia UI, or only > with gecko API's? Can you describe a complete test? > > Jonathan > > > On 10/29/2013 3:42 AM, Tim Chien wrote: >> >> Thanks for the information. >> >> I highly recommend to prioritize this work. These are the two scripts >> that sits in the critical launch path of the phone. If it breaks the >> phone won't boot, and it did due to many suspectable race conditions >> we found previously... >> >> >> >> On Tue, Oct 29, 2013 at 5:53 AM, Jonathan Griffin <[email protected]> >> wrote: >>> >>> We currently do not support browser_chrome_tests in B2G, and there are no >>> current plans to add support for it - all the existing browser_chrome >>> tests >>> are Firefox-specific. >>> >>> If there is a need for some hybrid gecko/gaia tests (and I believe there >>> likely is), we should carefully define what the capabilities of such >>> tests >>> should be, so we can architect an appropriate solution. >>> >>> Right now, I agree that gaia-ui-tests, or gaia-integration-tests (their >>> JS >>> equivalents) are the best places to write such tests, even though those >>> frameworks may be slightly awkward for this kind of verification. >>> >>> Jonathan >>> >>> >>> >>> On 10/28/2013 7:58 AM, Tim Chien wrote: >>>> >>>> Vivien, >>>> >>>> Thanks, that's very helpful. IMHO we should push this work to the FxOS >>>> roadmap. >>>> >>>> On Mon, Oct 28, 2013 at 6:57 PM, Vivien Nicolas <[email protected]> >>>> wrote: >>>>> >>>>> You likely want: >>>>> https://developer.mozilla.org/en-US/docs/Mochitest >>>>> https://developer.mozilla.org/en-US/docs/Browser_chrome_tests >>>>> >>>>> Cheers, >>>>> Vivien. >>>>> >>>>> >>>>> On 27/10/2013 08:57, Tim Chien wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> While working on DNT feature, I realized that our Gaia integration >>>>>> tests >>>>>> (Python and JS) can only assert the values of mozSettings database >>>>>> after >>>>>> the test programically select the setting ratio button in the Setting >>>>>> app. >>>>>> It is actually at [1] where we copy the value from mozSettings to >>>>>> Gecko >>>>>> pref(). >>>>>> >>>>>> While the code there are relatively small, I wonder if we could write >>>>>> any >>>>>> tests for them? Any pointer of documentation to write tests for this >>>>>> particular part of Gecko is greatly appreciated. Thanks. >>>>>> >>>>>> [1] >>>>>> >>>>>> >>>>>> >>>>>> http://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/settings.js#l434 >>>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> > -- 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
