We've seen instances where we have performance problems due to the platform, like constantly turning wifi on and off, but diagnosing the problem was difficult and it looked like marionette was just slowing down over the duration of the gaia-ui-tests. We'd like to have a set of tests run to ensure that we can safely run our set up code without slowing down, so it can help us isolate where in the platform the regression is coming from. If the regression is due to marionette, we hope to catch it using tests written in Bug 931044. rwood, jgriffin and I suggest that we: * ensure that each step of the setup process (wifi, bluetooth, etc) can be run repeatedly without performance degradation. Reason: We saw this a perf regrssion before with disabling/enabling wifi repeatedly, and that was hard to diagnose. How: similar mechanism to marionette performance tests written in Bug 931044, where we compare the first X iterations and the last X iterations for significant performance regressions. Include gaiatest utility functions here i.e. ** wait_for_element_displayed ** wait_for_element_not_displayed etc.
Status: NEW → ASSIGNED
Whiteboard: [c=automation p= s= u=]
Malini, as A-team are the owners of gaiatest, can we move this to A-team component, or maybe even close it?
(In reply to Zac C (:zac) from comment #1) > Malini, as A-team are the owners of gaiatest, can we move this to A-team > component, or maybe even close it? This is still a valid bug, and the tests that need to be written here are for gaiatest, so Testing:Gaia UI Tests is a sensible component for it, unless there's some other specific component that fits it better?
mdas, I see this component as just for the Functional tests. but yes, a lot of gaiatest bugs are haphazardly spread across this component and the Marionette one :/
QA Whiteboard: [fxosqa-auto-backlog-]
Firefox OS is not being worked on
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.