Preventing IE10 regressions
Benji York
benji.york at canonical.com
Wed Jan 30 14:58:51 UTC 2013
Goal
Keep IE10 fixes from regressing (once we get the GUI running on IE10)
Since we do not regularly develop or run the tests on IE10 (and that is
unlikely to materially change) we would benefit from some form of
continuous integration (CI) for (at a minimum) IE10.
Plan
We will write browser tests that can be run via Sauce Labs
(saucelabs.com) on IE10 against the Juju GUI charm.
We will have one or more tests written in Python, using the Sauce Labs
remote Selenium/Web Driver interface. Those tests will operate against
the Juju GUI charm running in EC2 (initially). The tests will be
triggered a hosted Jenkins instance (i.e., http://www.cloudbees.com/).
Rational
Sauce Labs: They provide an easy to use system that is free to Open
Source projects. Since they use standard Selenium/Web Driver libraries
we can transition to a different back end if the need presents itself.
GUI Charm: Since this is the primary form in which our users will be
consuming the software, it makes sense to be the form in which we test
it (at least in part). Additionally, deploying the charm is likely to
be the easiest route to getting the software running in an automated
fashion (and if it isn't we need to reconsider our charm design).
EC2: Getting the charm running in EC2 is a known quantity for most of
the developers on the team. Using Canonistack and/or LXC should be a
short step from there.
Jenkins: It is the dominant CI software, free hosting is available, and
we can easily transition from a hosted environment to running it
in-house if needed.
Python tests: There is considerable infrastructure available to Python
for us to leverage in this space.
--
Benji York
More information about the Juju-GUI
mailing list