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...@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.jagir...@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" <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/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.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
