Selenium Testing
Introduction
The Selenium test environment will be set up independent from the project that is being tested and it will have its own GIT repository. The testing framework used is TestNG, and the Selenium tests will be built with Maven (ran with Maven SureFire). The properties file will be generated with Maven AntRun.
Selenium Framework GIT URL: http://172.31.1.112:8080/summary/?r=Cognitive/Selenium_Framework.git (updated 09/08/2014)
Setting Up Maven Dependencies and Plugins
Sample pom.xml for Maven: pom.xml
Selenium
TestNG
Maven SureFire
testng.xml contains the test suite to be run. More explanation below.
Maven AntRun
Writes out the POM version of the Selenium test code to a file that is read and logged as part of the test report, so that we know what version of the test was used.
Project Structure
- Each page in the website will be contained within its own package.
- Tests for each page can be separated into separate classes for better organization/structure. For example, if a page contains multiple views or different tabs within the page.
- Order matters: In TestNG, test classes are run in alphabetical order. (The unit tests within each class are ran in alphabetical order as well.) If your tests are dependent on one another, they should be named respectively.
- Architecture Example:
Setting Up The TestNG Test Suite
TestNG runs according to the plan specified in the testng.xml file. See TestNG Documentation (testng.xml).
Sample testng.xml file: testng.xml
Note: Tests within a TestNG suite are made up of classes. Classes within a test are executed in alphabetical order while tests are executed in the order listed in the testng.xml file.
Logging
Logging will be done using log4testng. See Logger.java.
Use log4testng.properties to log INFO level messages to the console.
Using Selenium
- WebDriver is the main interface to use for testing, which represents an idealised web browser. The methods in this class fall into three categories:
- Control of the browser itself
- Selection of WebElements
- Debugging aids
The entire test suite should share one WebDriver so that context can be maintained throughout the test run. This is achieved by creating a base page class (e.g. BasePageTest.java) with a static WebDriver. All other test classes will extend the base page class. The base page class also contains frequently used methods.
- Web elements will be tested against "mock elements" that contain the attributes we expect to find in the element from the web page.
- The BaseElement abstract class will contain attributes that are shared by all web elements, and all the other Element classes will extend BaseElement
- Attributes will be tested by retrieving an attribute from the web element and the mock element. The two attributes will then be compared and checked for equality.
- The BaseElement abstract class will contain attributes that are shared by all web elements, and all the other Element classes will extend BaseElement
- Certain tests may have timing issues, so sleep the thread whenever you perform an action that may be asynchronous.
- Example:
- Example:
Testing Webpages with Multiple Login Accounts
- When testing a page using multiple login accounts, each instance of the page should have its own non-static web driver.
- The instances of the page will be instantiated using a factory constructor with a data provider that exists in the BasePageTest class. The individual web drivers will also be instantiated within the factory.
TestNG Tips
- Printing the xpath of an element after a failed test will help locate elements that need to be fixed.
Sample method for getting the xpath of an element:
The method should go in the base page class. - StaleElementException: A StaleElementException is thrown when the element you were interacting is destroyed then recreated. Elements in the DOM are often destroyed and recreated when a web page changes dynamically as users interact with it. When this happens the reference to the element in the DOM that you previously had becomes stale and you are no longer able to use this reference to interact with the element in the DOM. You will need to refresh your reference to find the element again. This can be done using a try catch block within a while loop. See example below.
- In a GWT project and maybe others, xpath might be a more reliable means of finding an element, as opposed to class name.
The End