You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chip Childers <ch...@sungard.com> on 2013/02/13 20:44:24 UTC
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+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
RE: [DISCUSS] UI automation using Python/Selenium
Posted by Parth Jagirdar <Pa...@citrix.com>.
This sounds like a great idea.
We can also Ensure that Selenium and existing Marvin are not overlapping efforts.
Thanks,
.. Parth
-----Original Message-----
From: prasanna [mailto:srivatsav.prasanna@gmail.com] On Behalf Of Prasanna Santhanam
Sent: Thursday, February 14, 2013 7:16 AM
To: cloudstack-dev@incubator.apache.org
Cc: Parth Jagirdar
Subject: Re: [DISCUSS] UI automation using Python/Selenium
On Thu, Feb 14, 2013 at 10:06:01AM -0500, Chip Childers wrote:
> On Thu, Feb 14, 2013 at 03:02:09PM +0530, Prasanna Santhanam wrote:
> > On Wed, Feb 13, 2013 at 02:44:24PM -0500, Chip Childers wrote:
> > > 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+Automa
> > > > tion+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?
> >
> > Parth / Chip,
> >
> > The collaboration for marvin automation is happening on
> > github:/cloudstack-qa ever since the IP clearance issues prevented
> > us from moving tests in to the ASF. I'm happy to give you commit
> > privileges there so we can collaborate with other contributors
> > interested in automated tests.
> >
> > --
> > Prasanna.,
> >
>
> Would you see Selenuim tests as being part of the Marvin suite? IMO,
> they are separate, and I'd like them to be worked within the ACS repo.
> Open to arguments to the contrary though!
>
Nope that's not what I meant. Selenium tests are seperate. They will of course land in the ACS repo eventually. But I wanted to bring together those writing functional / integration tests on one collaborative platform. In this case that was to be the github repo for cloudstack-qa. Contributors are free to choose their own repo as well. :)
--
Prasanna.,
Re: [DISCUSS] UI automation using Python/Selenium
Posted by Prasanna Santhanam <ts...@apache.org>.
On Thu, Feb 14, 2013 at 10:06:01AM -0500, Chip Childers wrote:
> On Thu, Feb 14, 2013 at 03:02:09PM +0530, Prasanna Santhanam wrote:
> > On Wed, Feb 13, 2013 at 02:44:24PM -0500, Chip Childers wrote:
> > > 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?
> >
> > Parth / Chip,
> >
> > The collaboration for marvin automation is happening on
> > github:/cloudstack-qa ever since the IP clearance issues prevented us
> > from moving tests in to the ASF. I'm happy to give you commit
> > privileges there so we can collaborate with other contributors
> > interested in automated tests.
> >
> > --
> > Prasanna.,
> >
>
> Would you see Selenuim tests as being part of the Marvin suite? IMO,
> they are separate, and I'd like them to be worked within the ACS repo.
> Open to arguments to the contrary though!
>
Nope that's not what I meant. Selenium tests are seperate. They will
of course land in the ACS repo eventually. But I wanted to bring
together those writing functional / integration tests on one
collaborative platform. In this case that was to be the github repo
for cloudstack-qa. Contributors are free to choose their own repo as
well. :)
--
Prasanna.,
Re: [DISCUSS] UI automation using Python/Selenium
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Feb 14, 2013 at 03:02:09PM +0530, Prasanna Santhanam wrote:
> On Wed, Feb 13, 2013 at 02:44:24PM -0500, Chip Childers wrote:
> > 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?
>
> Parth / Chip,
>
> The collaboration for marvin automation is happening on
> github:/cloudstack-qa ever since the IP clearance issues prevented us
> from moving tests in to the ASF. I'm happy to give you commit
> privileges there so we can collaborate with other contributors
> interested in automated tests.
>
> --
> Prasanna.,
>
Would you see Selenuim tests as being part of the Marvin suite? IMO,
they are separate, and I'd like them to be worked within the ACS repo.
Open to arguments to the contrary though!
-chip
Re: [DISCUSS] UI automation using Python/Selenium
Posted by Prasanna Santhanam <ts...@apache.org>.
On Wed, Feb 13, 2013 at 02:44:24PM -0500, Chip Childers wrote:
> 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?
Parth / Chip,
The collaboration for marvin automation is happening on
github:/cloudstack-qa ever since the IP clearance issues prevented us
from moving tests in to the ASF. I'm happy to give you commit
privileges there so we can collaborate with other contributors
interested in automated tests.
--
Prasanna.,
RE: [DISCUSS] UI automation using Python/Selenium
Posted by Parth Jagirdar <Pa...@citrix.com>.
We need to come up with a naming scheme. And what elements to include.
Any suggestions for that?
Thanks,
.. Parth
-----Original Message-----
From: Edison Su [mailto:Edison.su@citrix.com]
Sent: Monday, April 29, 2013 7:45 PM
To: dev@cloudstack.apache.org; Chip Childers
Subject: RE: [DISCUSS] UI automation using Python/Selenium
+1 on the unique names/Id, it's a life saver. The following code to find out UI element is unmaintainable:
instances_table_xpath = "/html/body/div/div/div[2]/div[2]/div[2]/div/div[2]/div[2]/table/tbody/tr/td/span"
> -----Original Message-----
> From: Parth Jagirdar [mailto:Parth.Jagirdar@citrix.com]
> Sent: Monday, April 29, 2013 7:17 PM
> To: dev@cloudstack.apache.org; Chip Childers
> Subject: Re: [DISCUSS] UI automation using Python/Selenium
>
> 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" <pr...@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.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/selec
> >t/
> >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/selec
> >t/
> >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.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
RE: [DISCUSS] UI automation using Python/Selenium
Posted by Edison Su <Ed...@citrix.com>.
+1 on the unique names/Id, it's a life saver. The following code to find out UI element is unmaintainable:
instances_table_xpath = "/html/body/div/div/div[2]/div[2]/div[2]/div/div[2]/div[2]/table/tbody/tr/td/span"
> -----Original Message-----
> From: Parth Jagirdar [mailto:Parth.Jagirdar@citrix.com]
> Sent: Monday, April 29, 2013 7:17 PM
> To: dev@cloudstack.apache.org; Chip Childers
> Subject: Re: [DISCUSS] UI automation using Python/Selenium
>
> 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" <pr...@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.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/
> >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.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
Re: [DISCUSS] UI automation using Python/Selenium
Posted by Parth Jagirdar <Pa...@citrix.com>.
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" <pr...@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.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/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.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
RE: [DISCUSS] UI automation using Python/Selenium
Posted by Pranav Saxena <pr...@citrix.com>.
[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
RE: [DISCUSS] UI automation using Python/Selenium
Posted by Parth Jagirdar <Pa...@citrix.com>.
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