Selenium WebDriver is rather new in the test automation world.

Before Selenium, all attention and spotlight belonged to a product called QTP (UFT is the new name), built by Mercury Interactive (owned now by HP).

Everyone was talking about QTP and Mercury so much that the Selenium creator, Jason Huggings, named his new automation tool after another chemical element, Selenium.

How does QTP work?

QTP allows automation tests to be created for a variety of application types in 2 different ways:

1. through record-and-play
2. through code

When using the record-and-play mode, the user goes through the following steps to record a new test:

1. opens the QTP application
2. selects the record button
3. selects the application to be tested
4. starts the recording
5. goes through the application like a normal user
6. stops the recording

After the recording is stopped, a new automated test is created.

The automated test can be played back.

Its code uses items from an object repository that is created during the recording process:

The object repository is a tree-like structure that has a node for each application element used during recording.

Each node has in the object repository multiple attributes:

1. name
2. class
3. type
4. locator
5. value

So the automation code works by interacting with application elements found in the object repository.

This seems a decent approach. Why not use it with Selenium WebDriver as well?

Test automation with Selenium WebDriver is done 100% through code.

There is a tool called Selenium IDE that relies on record-and-play but it is useless for serious test automation due to numerous limitations.

Test automation with Selenium WebDriver does not rely at all on record-and-play.

And object repository is a record-and-play concept.

Without recording the test, how would the object repository be created?

Does this mean though that the object repository cannot be used with Selenium automation?

Lets see how code looks when using an object repository.

We have a Home Page class that implements the user interaction with a typical Home Page such as the Hudson Bay’s one

The object repository for the page could be a property file (or xml, csv, yaml) as follows:

BRANDS = brands.id

WOMEN = women.id

SHOES = shoes.id

HANDBAGS = handbags.id

ACCESSORIES = accessories.id

BLACK_FRIDAY_SALE = blackfridaysale.id

BLACK_FRIDAY_DEAL = blackfridaydeal.id

The HomePage.java page object class uses the element ids from the object repository:

public class HomePage {

  private WebDriver driver;

  private PropertyFile props;

  private final String URL = “http://www.thebay.com";

  public HomePage (WebDriver driver) {

     this.driver = driver;

     this.props = new PropertyFile(“homePage.properties”);

  }

  public void open() {

    driver.get(URL);

  }

  public BrandsPage goToBrands() {

   By brandsId = By.id(props.(“BRANDS”));

   WebElement brands= driver.findElement(brandsId);

   brands.click();   

   return new BrandsPage(this.driver);   

  }

   public WomenApparelPage goToWomenApparel() {

     By womenId = By.id(props.get(“WOMEN”));

     WebElement women= driver.findElement(womenId);

     women.click();

     return new WomenApparelPage(this.driver);

  }

  .......................

}

I added only 2 methods to the class for the first 2 top menu options, Brands and Women.

Each method gets the menu option’s locator through an object of the PropertyFile class.

This class opens the property file, searches for a property name, gets the property value and returns it:

package Property;

import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.util.Properties;

public class PropertyFile {
 
 private final Properties properties;
 
 public PropertyFile(String fileName)
 {  
  try {   
     properties = new Properties();   
     File file = new File(fileName);
     InputStream input = new FileInputStream(file); 
     properties.load(input);   
  }
  catch (Exception exception) {
     throw new RuntimeException ("cannot load the property file");
  }  
 }
 
 public String get(String name)  {  
  try {
   return properties.getProperty(name);
  }
  catch(Exception exception) {
   throw new RuntimeException ("cannot find "+ name);
  }   
 }
}

What are the “advantages” of using an object repository?

1. All locators for the elements of a page are in 1 place
2. Since the page classes dont have locator variables, they are shorter.

You noticed, of course, that there are double quotes around advantages.

They are actually disadvantages.

What are the disadvantages of an object repository?

1. It is very difficult to read or change the value of an element locator

An ecommerce site has more than 50 pages, each with hundreds of elements.

We will have then an object repository for each page.

While working with code, there are many times when we need to either read or change the value of a locator.

Usually, this is done in the IDE (Eclipse, Intellij) by pressing the F3 key or selecting Open Declaration for the locator variable:

This does not work with object repositories since a locator is just a line in a text file.

To read or change the locator value, you have to

• find the object repository for the page
• open it
• search for the element name in the file

That’s a lot of work for just reading a locator value.

2. A page object class becomes a method container if it has no locator variables.

Page object classes are classes.

A JAVA class has variables for state and methods for behavior.

The methods operate on the variables of the class:

Encapsulation (computer programming)

From Wikipedia, the free encyclopedia

In programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:

- A language mechanism for restricting direct access to some of the object’s components.

- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

Removing the locator variables from a page object class means violating the encapsulation principle since

• the class does not have variables any longer
• its methods do not operate on the class variables

3. Using object repositories does not scale well for big page object classes

The HomePage class for the HudsonBay site will be big, with lots of locators and lots of methods.

Having big classes with more than 200 lines of code and more than 10 methods is a bad practice.

So they should be broken down in smaller classes.

We could do this for the HomePage by creating classes for the HomePage widgets:

• top menu widget
• sales and deals widget
• header (sign in, my account, gift cards, gift registry, etc)
• search
• best sellers
• black friday deals
• sponsored products
• footer

Using page element classes for all widgets will simplify the Home Page class significantly and allow us to keep it small.

But how do we do this with object repositories?

Use the HomePage repository for all page element classes?

Or create an object repository for each page widget?

4. Object repositories do not work well with the Page Factory pattern

This should be no surprise since Page Factory declares together web elements and their locators:

public class HomePage {

private WebDriver driver;

private final String URL = “http://www.thebay.com";

@FindBy(how = How.ID, using = "brands.id")

private WebElement brands;

@FindBy(how = How.ID, using = "women.id")

private WebElement women;

public HomePage (WebDriver driver) {

  this.driver = driver;

}

public void open() {

  driver.get(URL);

}

public BrandsPage goToBrands() {

   brands.click();

   return new BrandsPage(this.driver);

}

public WomenApparelPage goToWomenApparel() {

  women.click();

  return new WomenApparelPage(this.driver);

}

.......................

}

Why are people still suggesting using object repositories with Selenium WebDriver?

One reason may be that many testers learned Selenium WebDriver after working with QTP for a long time.

How QTP works became so familiar to them that they use QTP concepts everywhere.

Another reason may be that it is far easier to write procedural code (as in VB, VB SCRIPT) than object oriented code (as in JAVA or C#).

This article is inspired from a chapter of my new book on improving Selenium code with page object models.

You can find it on Amazon . com at

Improve Selenium Code with Automation Patterns: Page Object Model Page Factory Page Elements Base Page Loadable Component

How to create the driver object.

How to find elements.

How to switch to a frame.

How to create a page object.

I will do the opposite.

It is as useful, maybe even more, to see what you should not do.

One may think that, with such a great amount of available advice in blogs, courses and books, most test automation code is good or at least decent.

In reality, in most cases that I was exposed to, it is really bad.

The bad automation code may come from offshore automation “experts” or from local automation “consultants”.

No difference.

Every time I see samples of it, “what the fuck!” is the first reaction.

Source: https://www.osnews.com/story/19266/WTFs_m

I still remember how I reacted seeing this cartoon: laughing until I could not breathe any more.

These days, I am not laughing at all.

Because test automation becomes the place inhabited by either

- unprofessional developers, who failed at development

or

- manual testers converted to junior developers, who failed at manual testing

Some of these people have certifications as well to prove their lack of skills and knowledge:

I should probably be happy that so many people write awful code since there are more opportunities available.

I am frustrated instead.

Because that’s what is going on with manual testing as well.

There have been so many unprofessional manual testers out there and for such a long time that manual testing is slowly going away.

I will not be surprised if the same happens to test automation, change into application UI automation and be a development activity.

Who needs junior automation developers?
Or fake automation engineers?

What follows are code samples from “test automation experts”.

I did not make them up.

They are all real.

Wait For Page To Load

public void waitForPageToLoad(String string){
  String url = browserDriver.getCurrentUrl();
  Boolean stringExists = url.contains(string);
  int Count = 0;
 
  while (Boolean.FALSE.equals(stringExists) && Count < 100){
     url = browserDriver.getCurrentUrl();
     stringExists = url.contains(string);
     Count = Count + 1;
     try {
        Thread.sleep(500);
     } catch (InterruptedException e) {
         // TODO Auto-generated catch block
         e.printStackTrace();
     }
  }
 
   //if(stringExists==false)
   if(Boolean.FALSE.equals(stringExists))
      throw new IllegalStateException(
        “Page not loaded. Current page” + “is: “
         + browserDriver.getCurrentUrl()); 
   }
}

What’s wrong with this?

1. the method name is misleading; the method waits for the url to include a keyword and not for the page to load; a better name is isUrlCorrect()
2. do while() would work better than while
3. Boolean.FALSE.equals(stringExists) is the same with stringExists == false or !stringExists
4. the try/catch for waiting can be extracted in a method
5. the code for checking if the url contains a keyword can be extracted in a method
6. the exception does not say which page is not loaded
7. the parameter should be named keyword instead of string
8. Count should be count
9. Comments all over the place; not even // TODO Auto-generated catch block is removed

Can it be done better?

public void isUrlCorrect(String keyword){ 
  int count = 0;
 
   do { 
     count ++;
     waitFor(1);
   } while (urlContains(keyword) == false && count < 30);
 
   if(count == 30)
     throw new PageNotDisplayedException(“Page not loaded”);; 
}

private void urlContains(String keyword) {
   return driver.getCurrentUrl().contains(keyword);
}

Is this the correct way?

This is a case of reinventing the wheel.

The Selenium WebDriver library has explicit waits and expected conditions for checking if the url is correct:

WebDriverWait wait = new WebDriverWait(driver, 30);
wait.until(ExpectedConditions.urlContains(keyword));

Static Waits

public static void Wait(){
  try {
    Thread.sleep(2000);
  } catch (InterruptedException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
  }
}
 
public static void WaitMilliSeconds(int time){
  try {
    Thread.sleep(time);
  } catch (InterruptedException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
  }
}

What’s wrong with this?

The methods have duplicated code.

Can it be done better?

public static void wait(){
   wait(2000);
}
 
public static void wait(int time){
  try {
    Thread.sleep(time);
  } catch (InterruptedException e) { 
  }
}

Isnt this simpler?

Yes, it is called method overloading.

Date methods

public static String getDateString(int d) {
   DateFormat dateFormat = new SimpleDateFormat(“M/d/yyyy”);
   Calendar cal = Calendar.getInstance();
   cal.add(Calendar.DATE, d); 
   return dateFormat.format(cal.getTime());
}

Whats wrong with this?

Java 8 has the best date and time classes ever called LocalDate and LocalTime.

Why use date classes from older Java versions if they have much better replacements?

And now the main attractions….

Click elements

public void Click(){
  
  driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);

  try {
    wait.until(ExpectedConditions.elementToBeClickable(locator));
    driver.findElement(locator).click();
    System.out.println(“Clicked webelement at: “+locator );
  }
  catch (RuntimeException e) {
    System.out.println(e);
    WaitMilliSeconds(500);
    if (Boolean.FALSE.equals(
                    driver.findElement(locator).isEnabled()))
       throw new NoSuchElementException(
          “Elment not found at locator: “+ locator);

    driver.findElement(locator).click(); 
 }
 
} 

What’s wrong with this?

1. Click() should be click()
2. implicit and explicit waits are used together; this is a bad practice as it leads to unpredictable behaviours
3. information is displayed in the console; how is this useful for big tests running in parallel? if you have to log exceptions, at least log them in a file
4. an explicit wait waits until the element is displayed and clickable; then, the element is found again and is clicked; why should the element be found twice?
5. if there is an exception, if the element is not enabled, an exception is thrown; if the exception is caused by the element not being clickable, the code from the catch() clause is useless
   
   What the fuck??????

Can it be done better?

public void click(){ 
 WebElement element = this.wait.until(ExpectedConditions.
                            elementToBeClickable(this.locator));
 element.click();
}

If the element cannot be found or cannot be clicked, use a different way of finding and clicking it like Javascript.

SendKeys()

public void SendKeys(String text){
 wait = (new WebDriverWait(driver, 4));
 try
 {
    wait.until(ExpectedConditions
        .visibilityOfElementLocated(locator));
    driver.findElement(locator).sendKeys(text);
    System.out.println(“Entered sendKey text: “+text);
    //SendKeyEnter();
    System.out.println(“Click Enter”);
    WaitMilliSeconds(1000);
 }
 catch(RuntimeException e)
 {
    System.out.println(“\nSecond attempt to SendKey text:” + text);
    Wait();
    driver.findElement(locator).sendKeys(text);
    SendKeyEnter();
 }
 
}

What’s wrong with this?

1. SendKeys() should be sendKeys()
2. information is displayed in the console
3. an explicit wait waits until the element is displayed; visibilityOfElementLocated is used instead of elementToBeClickable;then, the element is found again and text is typed into it; why should the element be found twice?
4. if there is an exception, the element is found again and the text typed in it; then, enter is pressed; if the exception is caused because the element is not clickable (because, for example, it is not in the viewport), the code from the catch() clause is useless

Can it be done better?

public void sendKeys(String text){
  WebElement element = wait.until(ExpectedConditions
                          .visibilityOfElementLocated(locator));
  element.sendKeys(text);
}

Wait Until Web Element Clickable

public void WaitUntilWebElementClickable(){
 try {
   wait.until(ExpectedConditions.elementToBeClickable(locator));
 }
 catch (RuntimeException e) {
   WaitMilliSeconds(2000);
   driver.navigate().refresh();
   System.out.println(“refresh internally…”);
   wait.until(ExpectedConditions.elementToBeClickable(
        driver.findElement(locator))); 
 }
}

What’s wrong with this?

If there is an exception, wait for 2 seconds, then reload the page and try again.

If the element is not clickable, this may be because
1. it is disabled

2. it is not clickable

3. it is not in the view port

4. it is not displayed

Reloading the page does not fix any of these problems.

Can it be done better?

public void waitUntilElementClickable(){
 wait.until(ExpectedConditions.elementToBeClickable(locator)); 
}

getText

 
public String getText() {
 try {
   wait.until(ExpectedConditions
          .visibilityOfElementLocated(locator));
   return driver.findElement(locator).getText().toString().trim();
 }
 catch (RuntimeException e){
   System.out.println(“getText() exception: “+ e); 
   return “”;
 }
}

What’s wrong with this?

1. getText().toString() is useless since the getText() returns a string
2. If there is an exception, the method returns an empty string.
   
   If the element does not have a value, the method returns an empty string.
   
   So, what does an empty string mean? No element value or an exception happened?

Can it be done better?

public String getText() {
 WebElement element = wait.until(ExpectedConditions.
                         visibilityOfElementLocated(locator));
 return element.getText().trim(); 
}

refreshPageifNotClickable

public void refreshPageifNotClickable()
 {
  try {
    wait.until(ExpectedConditions.elementToBeClickable(locator));
    System.out.println(“\n “+locator+” is clickable”);
  }
  catch (RuntimeException e){
    driver.navigate().refresh();
    BaseHelper.WaitMilliSeconds(2000);
    WebElement we = driver.findElement(locator);
    wait.until(ExpectedConditions.elementToBeClickable(we));
  }
 }
 

Whats wrong with this?

Whats the purpose of the method?

To check if the element is clickable or to refresh the page?

Can it be done better?

Yes, by separating it in 2 methods, one for reloading the page, the other for checking if the element is clickable.

Is this useful? No.

I could continue over and over and over with these code samples.

Each is worse than the previous one.

One thing that is easy to observe is how non-object-oriented this code is.

Why non object oriented?

Because junior developers believe that, for test automation, there is no need to do development like a real developer.

Concepts like inheritance, composition, interfaces, polymorphism, refactoring, clean design are all unnecessary.

This is test automation and test goes first.

It is not called development automation so we can still be testers at it.

Code that works is sufficient.

So what companies get VB-written-in-Java or COBOL-written-in-C#.

As a summary, I want to say just one more thing.

You need to do development like a developer for good test automation.

You cannot do it yet?

Keep learning until you can.

Or please go back to where you came from, be it manual testing or something else.

Test automation does not need junior developers, only senior ones.