Pages

Wednesday, March 5, 2014

Page Object Design patterns

 

Page Object is a Design Pattern which has become popular in test automation for enhancing test maintenance and reducing code duplication. A page object is an object-oriented class that serves as an interface to a page of your AUT. The tests then use the methods of this page object class whenever they need to interact with that page of the UI. The benefit is that if the UI changes for the page, the tests themselves don’t need to change, only the code within the page object needs to change. Subsequently all changes to support that new UI are located in one place.
The Page Object Design Pattern provides the following advantages.
1. There is clean separation between test code and page specific code such as locators (or their use if you’re using a UI map) and layout.
2. There is single repository for the services or operations offered by the page rather than having these services scattered through out the tests.
In both cases this allows any modifications required due to UI changes to all be made in one place. Useful information on this technique can be found on numerous blogs as this ‘test design pattern’ is becoming widely used. We encourage the reader who wishes to know more to search the internet for blogs on this subject. Many have written on this design pattern and can provide useful tips beyond the scope of this user guide. To get you started, though, we’ll illustrate page objects with a simple example.
First, consider an example, typical of test automation, that does not use a page object.

/***
 * Tests login feature
 */
public class Login {

        public void testLogin() {
                selenium.type("inputBox", "testUser");
                selenium.type("password", "my supersecret password");
                selenium.click("sign-in");
                selenium.waitForPageToLoad("PageWaitPeriod");
                Assert.assertTrue(selenium.isElementPresent("compose button"),
                                "Login was unsuccessful");
        }
}
There are two problems with this approach.
  1. There is no separation between the test method and the AUTs locators (IDs in this example); both are intertwined in a single method. If the AUT’s UI changes its identifiers, layout, or how a login is input and processed, the test itself must change.
  2. The id-locators would be spread in multiple tests, all tests that had to use this login page.
Applying the page object techniques this example could be rewritten like this in the following example of a page object for a Sign-in page.

/**
 * Page Object encapsulates the Sign-in page.
 */
public class SignInPage {

        private Selenium selenium;

        public SignInPage(Selenium selenium) {
                this.selenium = selenium;
                if(!selenium.getTitle().equals("Sign in page")) {
                        throw new IllegalStateException("This is not sign in page, current page is: "
                                        +selenium.getLocation());
                }
        }

        /**
         * Login as valid user
         *
         * @param userName
         * @param password
         * @return HomePage object
         */
        public HomePage loginValidUser(String userName, String password) {
                selenium.type("usernamefield", userName);
                selenium.type("passwordfield", password);
                selenium.click("sign-in");
                selenium.waitForPageToLoad("waitPeriod");

                return new HomePage(selenium);
        }
}
and page object for a Home page could look like this.

/**
 * Page Object encapsulates the Home Page
 */
public class HomePage {

        private Selenium selenium;

        public HomePage(Selenium selenium) {
                if (!selenium.getTitle().equals("Home Page of logged in user")) {
                        throw new IllegalStateException("This is not Home Page of logged in user, current page" +
                                        "is: " +selenium.getLocation());
                }
        }

        public HomePage manageProfile() {
                // Page encapsulation to manage profile functionality
                return new HomePage(selenium);
        }

        /*More methods offering the services represented by Home Page
        of Logged User. These methods in turn might return more Page Objects
        for example click on Compose mail button could return ComposeMail class object*/

}
So now, the login test would use these two page objects as follows.

/***
 * Tests login feature
 */
public class TestLogin {

        public void testLogin() {
                SignInPage signInPage = new SignInPage(selenium);
                HomePage homePage = signInPage.loginValidUser("userName", "password");
                Assert.assertTrue(selenium.isElementPresent("compose button"),
                                "Login was unsuccessful");
        }
}
There is a lot of flexibility in how the page objects may be designed, but there are a few basic rules for getting the desired maintainability of your test code. Page objects themselves should never be make verifications or assertions. This is part of your test and should always be within the test’s code, never in an page object. The page object will contain the representation of the page, and the services the page provides via methods but no code related to what is being tested should be within the page object.
There is one, single, verification which can, and should, be within the page object and that is to verify that the page, and possibly critical elements on the page, were loaded correctly. This verification should be done while instantiating the page object. In the examples above, both the SignInPage and HomePage constructors check that the expected page is available and ready for requests from the test.
A page object does not necessarily need to represent an entire page. The Page Object design pattern could be used to represent components on a page. If a page in the AUT has multiple components, it may improved maintainability if there was a separate page object for each component.
There are other design patterns that also may be used in testing. Some use a Page Factory for instantiating their page objects. Discussing all of these is beyond the scope of this user guide. Here, we merely want to introduce the concepts to make the reader aware of some of the things that can be done. As was mentioned earlier, many have blogged on this topic and we encourage the reader to search for blogs on these topics.

Monday, February 10, 2014

Selenium WebDriver


WebDriver is a tool for automating web application testing, and in particular to verify that functionalities work as expected. It aims to provide a friendly API that’s easy to explore and understand, easier to use than the Selenium-RC (1.0) API, which will help to make your tests easier to read and maintain.
Let us first get clarified about the difference types of selenium that is/was available in the past and the present.
Selenium Core is the heart of the original Selenium implementation, and is a set of JavaScript scripts that control the browser. This is sometimes referred to as “Selenium” and sometimes as “Core”.
Selenium RC was the name given to the language bindings for Selenium Core, and is commonly, referred to as just “Selenium” or “RC”. This actually came up with two components. Selenium server and the client libraries.
.Selenium WebDriver fits in the same role as RC did, and has incorporated the original 1.x bindings. It refers to both the language bindings and the implementations of the individual browser controlling code. This is commonly referred to as just “WebDriver” or sometimes as Selenium 2.
Selenium1.0+WebDriver=Selenium 2.0
SELENIUM WEBDRIVER WORKING
    WebDriver is designed in a simpler and more concise programming interface along with addressing some limitations in the Selenium-RC API.
    WebDriver is a compact Object Oriented API when compared to Selenium1.0
    WebDriver works at the OS/browser level:
    For instance, command type works at the OS level rather than changing the value of the input elements with JavaScript
    It drives the browser much more effectively and over comes the limitations of Selenium 1.x which affected our functional test coverage, like the file upload or download, pop-ups and dialogs barrier or self-signed certificates problems
Selenium RC, It ‘injects’ JavaScript functions into the browser when the browser was loaded and then used its JavaScript to drive the AUT within the browser. WebDriver does not use this technique. Again, it drives the browser directly using the browser’s built in support for automation.
WebDriver drives the tests natively with the browser and emulates the Human interaction with website. Implementation differs on each browser’s.
The merge of the projects combines the strengths of both frameworks: Selenium 2.0 will provide both Selenium 1.x and WebDriver APIs.
This document concentrates more on WebDriver implementation using the WebDriver Java API.
WebDriver is the name of the key interface against which tests should be written, but there are 11 implementing classes, listed as below:
    AndroidDriver,
    AndroidWebDriver,
    ChromeDriver,
    EventFiringWebDriver,
    FirefoxDriver,
    HtmlUnitDriver,
    InternetExplorerDriver,
    IPhoneDriver,
    IPhoneSimulatorDriver,
    RemoteWebDriver,
    SafariDriver

Selenium Vs Webdriver



Selenium uses JavaScript to automate web pages. This lets it interact very tightly with web content, and was one of the first automation tools to support Ajax and other heavily dynamic pages. However, this also means Selenium runs inside the JavaScript sandbox. This means you need to run the Selenium-RC server to get around the same-origin policy, which can sometimes cause issues with browser setup.

WebDriver on the other hand uses native automation from each language. While this means it takes longer to support new browsers/languages, it does offer a much closer ‘feel’ to the browser. If you’re happy with WebDriver, stick with it, it’s the future. There are limitations and bugs right now, but if they’re not stopping you, go for it.
Selenium Benefits over WebDriver
* Supports many browsers and many languages, WebDriver needs native implementations for each new languagte/browser combo.
* Very mature and complete API
* Currently (Sept 2010) supports JavaScript alerts and confirms better
Benefits of WebDriver Compared to Selenium
* Native automation faster and a little less prone to error and browser configuration
* Does not Requires Selenium-RC Server to be running
* Access to headlessHTMLUnit can allow really fast tests
* Great API