incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pranav Saxena <pranav.sax...@citrix.com>
Subject RE: [DISCUSS] UI automation using Python/Selenium
Date Thu, 14 Feb 2013 18:38:38 GMT
[CHIP]
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

We are having discussion about this and should be able to get the relevant changes done in
sometime (associating ID's with the UI elements) so that UI automation could be done in a
more sturdy way .

Regards,
Pranav

-----Original Message-----
From: Parth Jagirdar [mailto:Parth.Jagirdar@citrix.com] 
Sent: Friday, February 15, 2013 12:00 AM
To: Chip Childers; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] UI automation using Python/Selenium

Hi Chip,


For following::


[CHIP]
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.

[PARTH]
Yes, Main .py is the executable.
We import other modules
Each class in each module is a test case.
And then we serialize them into main.


[CHIP]
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.

[PARTH]
Xpath is least reliable. ID and Name tops the reliability. But for now no choice.
However I have created a global file which looks like

# Selects Templates from drop down
template_xpath = "/html/body/div/div/div[2]/div[2]/div[2]/div/div[2]/div/div/div/select/option[1]"

# Selects ISO from drop down
iso_xpath = "/html/body/div/div/div[2]/div[2]/div[2]/div/div[2]/div/div/div/select/option[2]"

# Add Template
AddTemplate_xpath = "//div[3]/span"

We are essentially using these variables across all the classes and modules. So in event of
script failure we look at the element location (using xpath finder) and match it with our
global file. If they differ we update accordingly.
Also note that terminal elements (ones that are reachable by only one way, Like a house on
dead end street) I have hard coded them into scripts. Because if these paths change and scripts
fail we know where to look at.

Also, all similar test cases say service offerings are in one module service_offerings.py.
 which contains disk/compute/system offerings with Add/Edit and Delete test cases.
We should be able to perform a replace easily if needed.



[CHIP]
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).
[PARTH]
Absolutely.


Thanks,
.. Parth


-----Original Message-----
From: Chip Childers [mailto:chip.childers@sungard.com] 
Sent: Wednesday, February 13, 2013 11:44 AM
To: cloudstack-dev@incubator.apache.org; Parth Jagirdar
Subject: Re: [DISCUSS] UI automation using Python/Selenium

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+u
> sing+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