Friday, February 13, 2015
If you are into automation testing using selenium, you may be knowing about the Page Object Pattern suggested by selenium forum available at url :
https://code.google.com/p/selenium/wiki/PageObjects
The documentation suggests the approach for implementing Page Object Pattern for automation and what are the advantages of it. In here I wont be writing about what the documentation suggests and talks about it. So lets directly jump onto the main subject and learn about what the documentation does not contain. Following are those points:
With new web application development technologies coming into play on a daily basis web applications has reduced to very few pages and even sometimes to one page url. This becomes a challenge while implementing Page Object Pattern. The question arises is, how to segregate the pages as there are only few pages in the application but there are lot of functionalities to cover in them. If we go ahead with the conventional segregation methodologies we will have very few page classes but with lot of functional methods defined in them. We will fall into the same problem of code management that we were trying to solve using Page Object Pattern.
The solution to this is to enhance the Page Object Pattern guidelines. This includes segregating your page classes based on features, sub-features, functionality etc. and not by page urls. To explain this we have a perfect example of Gmail. Gmail is a single page but there are lot of functionalities available in the said page like navigation, hangouts, inbox, Search, compose and mail folders.
If we go with the conventional method we will be forced to define all the functionalities of compose, hangouts contacts chat, inbox etc in a single class. With the enhanced model we will define separate classes for each of the feature ex. ComposePage, HangoutPage, InboxPage, NavigationPage etc. By using the enhanced model we can fully utilize the advantages of using the Page Object Pattern.
The guideline suggests users to define functionalities as method inside page classes and it ends there. It does not talk much about the segregation, approach or anything of such sort. Anyways lets cover it here. When planning to define methods for the functionality try to follow following added guidelines:
The above suggestion helps in making tests more readable, manageable and in providing more functionality to the user who is automating. The initial time taken to write page class and page methods will be more but there will be very less time spent on writing automation test cases for the said functionality as the methods list will contain methods that supports all kind of related functionality from low level to high level as well as both positive and negative scenarios.
This is a cross post from my company blog here, where I had originally written it.
https://code.google.com/p/selenium/wiki/PageObjects
The documentation suggests the approach for implementing Page Object Pattern for automation and what are the advantages of it. In here I wont be writing about what the documentation suggests and talks about it. So lets directly jump onto the main subject and learn about what the documentation does not contain. Following are those points:
- Implementing a Page Object Pattern for a single page application
- Approach towards defining methods for functionality
Implementing Page Object Pattern for a single page application
With new web application development technologies coming into play on a daily basis web applications has reduced to very few pages and even sometimes to one page url. This becomes a challenge while implementing Page Object Pattern. The question arises is, how to segregate the pages as there are only few pages in the application but there are lot of functionalities to cover in them. If we go ahead with the conventional segregation methodologies we will have very few page classes but with lot of functional methods defined in them. We will fall into the same problem of code management that we were trying to solve using Page Object Pattern.
The solution to this is to enhance the Page Object Pattern guidelines. This includes segregating your page classes based on features, sub-features, functionality etc. and not by page urls. To explain this we have a perfect example of Gmail. Gmail is a single page but there are lot of functionalities available in the said page like navigation, hangouts, inbox, Search, compose and mail folders.
If we go with the conventional method we will be forced to define all the functionalities of compose, hangouts contacts chat, inbox etc in a single class. With the enhanced model we will define separate classes for each of the feature ex. ComposePage, HangoutPage, InboxPage, NavigationPage etc. By using the enhanced model we can fully utilize the advantages of using the Page Object Pattern.
Defining methods for Page functionality
The guideline suggests users to define functionalities as method inside page classes and it ends there. It does not talk much about the segregation, approach or anything of such sort. Anyways lets cover it here. When planning to define methods for the functionality try to follow following added guidelines:
- Segregate your functionality into smaller functionally executed methods. Lets take an example of login use case where user enters username, password and click on submit button. While writing a functional method for login you should think of having methods like enter username, enter password and clicking on submit button. This way you will have more control on the code and you can provide more utilities to user who is writing automation tests.
- Think of functional as well as structural method declarations. Taking the above example. login method that accepts username and password arguments is a functional method whereas enter username, enter password and click on submit button methods are structural methods. As said in the first point structural methods makes code more readable and represents a flow of user actions. It also provide more power into the hands of end user who is using them for writing automation tests.
- Think of positive and negative scenarios of a functionality while defining methods. I will again take the example of the login functionality. A login can be successful or it can be failure. try to support both kind of scenarios in a single method. This can be achieved in two ways:
- Allow a Boolean value to be passed as argument to the method that will decide whether the scenario for which the method is being used in positive or negative.
- Another way is you written a Boolean or some other object as return type representing whether the method execution was success or a failure.
The above suggestion helps in making tests more readable, manageable and in providing more functionality to the user who is automating. The initial time taken to write page class and page methods will be more but there will be very less time spent on writing automation test cases for the said functionality as the methods list will contain methods that supports all kind of related functionality from low level to high level as well as both positive and negative scenarios.
This is a cross post from my company blog here, where I had originally written it.
Monday, February 9, 2015
While using selenium for web automation many a time we face numerous kind of exceptions. Many of these exceptions are mainly selenium exceptions. In this blog I will write about few of those selenium exceptions, why they occur and how to resolve/avoid them.
- StaleElementReferenceException -
As the name suggests this exception occurs when the element stale, which means the element reference on which you are trying to take a action upon is no longer available on the page or has changed.
To avoid this exception, try to find the element as and when you need to take an action upon it rather than getting the element at some point of code and then reusing it at different places. - InvalidCoordinatesException -
This exception occurs when invalid co-ordinates are provided for an interaction operation like move, click, drag & drop etc.
You can avoid this exception by identifying a Webelement on the page for interaction rather than providing a co-ordinates. - ElementNotVisibleException -
This exception occurs when an element may be available in the dom but not displayed on the page and hence not able to be interacted. This exception may also occurs if the element is unable to scroll onto the browser view.
You can avoid this exception by verifying that the element is visible and then taking action on the element. There are some methods present in "ExpectedConditions" class that can be used to wait for the element to be visible. These methods are "visibilityOf(Webelement)" and "visibilityOfElementLocated(By)". - InvalidSelectorException -
This exception is thrown when the selector used to find the element is invalid or wrong, this may be a syntax error or a compound class name to be provided to "By.className" method.
To avoid this exception verify that the selector that you are using are verified on the said page using jQuery or firebug or firepath. - NoSuchElementException -
This is a common exception faced by selenium users and occurs when there is no element found on the current page by selenium based on the user provided selector to method "findElement". There can be multiple reasons for this exception to occur like selector being wrong, element taking time load(in case of ajax), earlier step execution failed etc.
You can avoid this exception by implementation by waiting for element to be present using "FluentWait" with "ExpectedConditions" class methods "presenceOfElementLocated(By)" and "visibilityOfElementLocated(By)". - UnreachableBrowserException -
This exception mainly occurs due to two reasons first when the browser to which the selenium commands has died mid-test and second when the remote server address to which the RemoteWebDriver trying to contact is invalid.
There is no proper solution to this error you can only take precautionary measures in this cases and is more or less related to hardware.
Subscribe to:
Posts
(
Atom
)
