January 1, 2018January 4, 2018 Ravi Beck

10 coding watchouts for an Automation Developer – Part 1

Development, QA

How do you solve this mathematical problem such as this?

9+(5*3)/2

You apply the BODMAS rule first, wouldn’t you? BODMAS is a mathematical rule when all your operations are the same level (for example, all division or multiplication), simply work from left to right.The same applies to anything that you learn at a fundamental level. There are rules to how software is designed and how it works, irrespective of the application.

The objective of this article is to discuss the fundamental rules of automation testing and design.

It is not a difficult job to write automated test scripts but writing them in a wrong way will lead to poorly implemented tests and the high cost of code maintenance. UI tests are essential part of any agile process as it ensures a positive user experience.

If you are automating your tests for Web based applications, Selenium-WebDriver is the best available option. Not only it is an open source tool but also widely being used and well supported by the community.

So let us discuss the key factors to be taken into account before jump starting your automation test cases.

1.   Page Objects

Before we jump into page objects, let us quickly understand what is a page? A page is a representation of content or a form to collect data. Let us consider a website like Wikipedia which is the best example for a page with data. When you edit the Wiki page you are obviously editing it on a form that will collect the data and store it.

Now what is a typical website page made of? It is usually multiple Elements like text, fields, field names, radio buttons, check box, calendar and buttons etc… right?

In automation you are essentially trying to mimic what a user will do using the page objects. The might read text on the screen or fill up a form, do some action on the website or a web application.

Page objects lets you breakdown the website or web application one page or a function at a time and capture the elements into a single class. This can be reused to create different scenarios based on what a user would do, helping us completely automate the system. In Page Object Model the Object information is managed outside the test script, thus making the test script understandable. Moreover it makes the code readable, reusable, optimized and less in volume. Its advantage is that in case of UI revamps, the tests remains intact, only the code within the page object needs to change. Subsequently all changes to support that new UI are located in one place. The tests then use the methods of this page object class whenever they need to interact with that page of the UI. This reduces the amount of duplicated code that means if the UI changes, the fix need only be applied in one place.

2.  Selection of Locators

Just like how you will locate a person using an address, you will have to locate the elements in a page using IDs or Name or Xpath locators.

Unlike real-life, IDs in a page continue to change. The reason could be the developer could have changed it or the IDs are generated dynamically. You’ll have to get used to updating them as the development teams experiment with design, streamline HTML and fix bugs as long as your web app is evolving.

API tests and Unit tests are always faster but UI automation tests are comparatively slower. One of the major deciding factor is how fast the webdriver locates the  elements which again depends on the element locator. But you can always use a good locator over the poorly written ones.

Here is the list of the best and fastest selectors Selenium WebDriver Tests run faster:

2.1 ID selectors: IDs being the fastest and safest way are always preferred over any other locators. IDs should be unique in every page according to W3C standard
Now even if the DOM changes, if the ID is still there, then WebDriver can locate it.

2.2 CSS and Name selectors: If ID is not available then css locators are prefered over Xpath. CSS and Name locators are very similar but not very flexible in identifying elements comparing to XPath.

2.3 XPath locators: It is the most flexible but more fragile in order to build reliable web element locators however it is very slow as it needs to traverse the whole DOM of the page in order to traverse.

Click here for Part 2

By:
Ravi Beck
www.coviam.com