cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] UI automation using Python/Selenium
Date Wed, 13 Feb 2013 19:44:24 GMT
On Thu, Jan 17, 2013 at 10:09:06PM +0000, Parth Jagirdar wrote:
> Here is cwiki link...
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+Automation+using+Selenium+and+Python

Following up on this...

First, I love this initiative and want to help.  Since you don't have
commit rights, do you want to push to a github repo where others can
fork and submit pull requests for the feature?

A couple of comments on your PDF document (although it might be better
if the content was actually on the wiki page for collaboration):

I'd like to suggest that the tests are classified, based on the external
dependencies that they will require.  For example, running tests against
a DevCloud2 image / VirtualBox varient with nothing configured, vs.
basic zone enabled vs. advanced zone enabled, etc...  You get the point.
We need to be able to select the appropriate suite of tests at the time
they are run, but have them pre-classified for testers.

I've always used some form of a headless setup for running tests, and
have tended to use individual python files to group the raw tests in
ways similar to what I'm suggesting above.

The more these tests are tied to configurations that are also stored in
the repo, the better (in my example, the devcloud.cfg files are the
right way to start).

In your design doc, you mention that Main.py will be the executable
file.  Either it needs to support flags to trigger different suites, or
it can simply be exploded into multiple "main" files that drive the
correct suite.

As for element locators, you're right about the difficulty in the
current page DOM.  XPath seems to be the only reasonable way for now.
I'd assume that we would want to open bugs on key elements that should
actually have an ID, to make the test suite a bit more robust (less
prone to issues as the UI is tweaked over time).

The section that talks about Dynamically Generated elements is good, and
that proposed approach will work.  It's potentially brittle though.  The
only other idea I had was to allow the python code to call into the CS
API at appropriate times to determine bits of data that are necessary to
the UI automations.

Thoughts?

-chip

Mime
View raw message