Hey Tim,
Thanks for your response.
We're currently thinking about ways to fill testing gaps like this; can
you spec out what a single test case would need to do to verify these
concerns?
Jonathan
On 10/29/2013 9:21 PM, Tim Chien wrote:
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
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
