Bringing this back on tableŠ
As we have discussed this in past, That we need to have ID's/Names for UI
elements.
The challenge is to come up with a standard naming scheme to accomplish
this task.
How many unique names?
1)
Can we just get away with associating ID's with basic elements (and often
accessed elements)?
say for example :
- Dashboard/Network/Instances and almost every icon on Dashboard screen.
(Almost Always clicked multiple times in each test case, often in middle
of a test case for a clean start)
- VM operations icons. Start Stop etc etcŠ
- Template operations etc etc. ( this can be a long list so need help to
think of a way we can limit this)
- Some other valuable objects are Tables containing data VM's, Networks
all is listed in tables on UI::
Following snippet is almost always used to find the VM we created in our
tests.
We actually traverse through the table to find our VM with a string match.
Now if we can have a name for this table column (say Instances_table) ..
Life will be much simpler.
Such tables are used frequently on UI.
linkclass = None
linkclass =
driver.find_elements_by_xpath(Global_Locators.instances_table_xpath) #
This returns a list of all VM names in tables
for link in linkclass:
if link.text == "Auto-VM": # We will search for our VM in this table
print "found VM in table .. checking status..." + '\n' + '\n'
link.click()
status = driver.find_element_by_xpath(Global_Locators.state_xpath).text
## get the status of our VM
if status == "Running" : # then click and do something ...
In shortŠ Any suggestions?
1) Standard procedure to, name elements or associate ID's to them. (A Page
on wiki and a standard that committers/reviewers can enforce so we can
ensure that new features and bug fixes both comply with it)
2) Identifying which elements to start with. (inputs needed to define that
fine line)
.. Parth
On 2/14/13 10:38 AM, "Pranav Saxena" <pranav.sax...@citrix.com> wrote:
>[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.jagir...@citrix.com]
>Sent: Friday, February 15, 2013 12:00 AM
>To: Chip Childers; cloudstack-...@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/opt
>ion[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/opt
>ion[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.child...@sungard.com]
>Sent: Wednesday, February 13, 2013 11:44 AM
>To: cloudstack-...@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
