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.child...@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
