Posts by Alex Siminiuc

me

What is a selenium tester doing in real time

If you missed the previous day, you can find it here.

Morning of January 18

I start the day with something to bring my mood and energy up.
One cup of hot, strong coffee (no sugar, no milk) for the energy and Rammstein music for the mood.

Today, I need to focus on test stability issues.

I have around 20 Jenkins jobs that run daily automated tests related to various site features.

Some jobs pass consistently but a few fail from time to time.

The first one that I will look at is for the ChangePassword feature.

It runs all tests from the ChangePassword test class using a Maven command:

mvn clean -Dtest=automatedtests.changePassword.ChangePasswordTests test

Out of 5 job runs, there are 2 failures. The Jenkins console log says that assertions are failing. I will run the test class locally to see what is going on.

 

15 minutes later

From all change password tests, the one that changes the password successfully works. All other negative tests that verify that the password cannot be changed (if it is too short or if it includes special characters) fail. Each negative test attempts changing the password and then checks if an error message is displayed.

 

But the error message is all the time the same. It should say that the password is too short or that the password cannot include special characters. Instead, it always says that the passwords are not identical.

 

This seems like an application bug so I should speak to the developers. I will record a video with the tests execution and send it in an email asking for their opinion. Maybe there is a good explanation for it. I better get their opinion first and then, if they agree, log a bug to Jira.

 

10 minutes later

The email is out so I can look into the second failing Jenkins job. This one is about the user acount security questions.

The Jenkins console log points to timeout issues for different page elements.

There are a few possible reasons:

  • The site is very slow.
  • The test does not navigate from a page to the next one. Maybe the test executes the code for clicking a button and the button is not clicked.
  • The ids of the elements changed again.

The html of the site is pretty bad with many elements having either no ids or dynamic ids.

I will have to run these tests locally as well, then confirm which elements cannot be found, get their ids and compare them to the page element ids from Chrome Inspector.

So booooriiiing, does anyone like to do this part?

Anyways, as Maximus’s servant said it in Gladiator  (what a terrific movie! looking forward to watch it again) when asked if he likes what he does:

Maximus: Do you find it hard to do your duty?
Cicero: Sometimes I do what I want to do. The rest of the time, I do what I have to.

I will do as well what I have to.

Reluctantly 😦

 

Later in the day

I am really upset now. All elements from the security questions page have different ids. I need to modify all locators from the SecurityQuestions.java class and retest all tests that use it.

This is such a waste of effort, modifying page element locators over and over and over.

Starting from scratch 🙂

Too bad that the developers are so busy with the new features that no one has time to add the custom ids that I keep asking for.

I am so looking forward to the end of the sprint. Maybe after it, I will be able to pair with a developer and go through all pages and add custom ids to all elements.

Fingers crossed!

 

Finally, the last failing Jenkins job.

This one is for the user registration tests.

The console log shows stale element exceptions for a few elements. This is weird since I am sure that these tests were running very well.

Maybe the developers enabled the auto postback setting for the page elements which makes the element regenerate every time it is interacted with. I solved this before for other pages by retrying a method on exception a few times so I can do the same here. But since it is later in the day, it will have to wait until tomorrow.

 

4 pm already?

Before I go home, someone mentioned on LinkedIn that page factory should not be used any longer.

It is the video of the keynote of a Selenium conference from 2016. I better watch it to get more details.

 

4.30 pm

Yes, Simon Stewart says that no one is using Page Factory and that its design could have been better.

But apparently, no one uses it correctly either and many people try to generate page objects automatically while using page factory.

Wow, never crossed my mind to generate page objects automatically!

So Page Factory works if you use it as it is supposed to be used.

I should watch this video again.

I laughed so much during it, Simon has a great sense of humor 🙂

Advertisements

Use streams for lists of web elements

2179048[1]

Every time you need to find multiple elements in your Selenium code, you get a list of web elements, so a collection.

Streams and predicates, introduced in Java 8, are the best way of working with collections.

When you use them, you don’t only get code that is shorter and easier to understand but also better performance.

Why is this useful for you, a Selenium WebDriver developer?

It is useful because instead of getting texts and attributes of all elements (matched by the same locator) with

private List< String > textValues(By locator) {
  List elements = driver.findElements(locator);

  List< String > values = new ArrayList<>();

  for (WebElement e : elements)
    values.add(e.getText());

  return values;
}

private List< String > attrValues(By locator, String name) {
  List elements = driver.findElements(locator);

  List< String > values = new ArrayList<>();

  for (WebElement e : elements)
    values.add(e.getAttribute(name));

  return values;
}

you can use

private List< String > textValues(By loc) {
  return getValues(loc, e -> e.getText());
}

private List< String > attrValues(By loc, String name) {
  return getValues(loc, e -> e.getAttribute(name));

private List< String > getValues(
By loc, Function<WebElement,String > pred) {

  List< WebElement > elements = driver.findElements(loc);       

  List< String > values = elements.stream().map(pred)
                                  .collect(Collectors.toList());

  return values;


}

Read along to understand why the second code version is much better.

How to use collections the old way

Assume that you have a Result class for results of a page:

public class Result {

  private String name;
  private int price;
  private String owner;
  private boolean onlineOnly;

  public Result(String name, int price, String owner, boolean onlineOnly) {
    this.name = name;
    this.price = price;
    this.owner = owner;
    this.onlineOnly = onlineOnly;
  }

  public String name() {
    return this.name;
  }

  public int price() {
    return this.price;
  }

  public String owner () {
    return this.owner;
  }

  public boolean onlineOnly() {
    return this.onlineOnly;
  }

  @Override
  public String toString() {
    return name + " - " + price + " - " + owner + " - " + onlineOnly;
  }

}

You need also a Results class (for lists of results):

public class Results {

  List< Result > results;

  public Results(List results) {
    this.results = results;
  }

  public List< Result > get() {
    return this.results;
  }

  public Result getResult(int i) {
    return this.results.get(i);
  }

  public int size() {
    return this.results.size();
  }

  @Override
  public String toString() {
    return this.results.toString();
  }

}

So far, Results class has methods for returning

  • the list of results
  • an element of the list
  • the size of the list
  • a String value for the list

Pretty basic, so far.

We would like to add filtering methods to the Results class such as:

public Results filterByOnlineOnly() {
  List< Result > list = new ArrayList()<>;

  for (Result r : this.results)
    if (r.onlineOnly() == true)
      list.add(r);

  return new Results(list);
}

public Results filterByOwner(String name) {
  List< Result > list = new ArrayList()<>;

  for (Result r : this.results)
    if (r.owner().equals(name))
      list.add(r);

  return new Results(list);
}

public Results filterByName(String name) {
  List< Result > list = new ArrayList()<>;

  for (Result r : this.results)
    if (r.name().equals(name))
      list.add(r);

  return new Results(list);
}

public Results filterByPrice(int price) {
  List< Result > list = new ArrayList()<>;

  for (Result r : this.results)
    if (r.price() == price)
      list.add(r);

  return new Results(list);
}

So far, we have filtering methods by name, owner, price and online only.

But, what should we do if we need more filtering methods such as

  • by price in a range
  • with a keyword in the name
  • with a keyword in the name and a specific owner

Adding more methods to the Results class is not the solution.

The more filters we need, the more methods.

One thing that is easy to notice is that all filtering methods have very similar code.

The only exception is the condition that the list elements should match.

How to use collections with streams and predicates

We can replace all methods with one method that uses a predicate parameter (for the filtering condition).

public Results filterBy(Predicate predicate) {

  List< Result > list = this.results.stream()
                  .filter(predicate)
                  .collect(Collectors.toList());

  return new Results(list);
}

How does this work?

  1. First, the results list is converted to a stream by the stream() method.
  2. Then, the filter() method filters the stream with the predicate . This is done by going through each element of the stream, applying the predicate to each element and selecting only the elements that match the predicate.
  3. Finally, collect() collects all selected elements and returns them as another list.

Amazing, isn’t it?

How can this method be used?

Results products = results.filterBy(r -> r.onlineOnly() == true);

Results products = results.filterBy(r -> r.name().equals("IPHONE 8"));

Results products = results.filterBy(r -> r.price() == 500);

We can get really creative now:

Results list = results.filterBy(r -> r.name().contains("IPHONE"));

Results products = results.filterBy(r -> r.name().contains("IPHONE") &&
                                         r.price() > 500 &&
                                         r.price() < 1000 &&
                                         r.onlineOnly() == false);

What else can you do with streams?

How about creating the list of all names, or all prices or all owners?

public List < String > values(Predicate predicate) {
  List list = this.results.stream()
                          .map(predicate)
                          .collect(Collectors.toList());

  return list;
}

Notice that the filter() method is replaced by the map().
map() extracts the value as specified by the predicate.
The method returns a list of Strings since names and owners are Strings:

List< String > owners = results.values(r -> r.owner());

List< String > names = results.values(r -> r.names());

There are many other things that can be done with streams and predicates:

Results onlineProducts = results.stream()
                                .filter(Result::onlineOnly)
                                .skip(1)
                                .collect(Collectors.toList());

Results cheapProducts = results.stream()
                           .filter(r -> r.price() <= 100)                                               .filter(r -> r.owner().equals("Rogers"))
                           .collect(Collectors.toList());

List< String > distinctOwners = results.stream()
                             .map(Result::owner)
                             .distinct()
                             .collect(Collectors.toList());

int priceSum = results.stream()
                      .map(Result::price)
                      .reduce(0, Integer::sum);

assertTrue(results.stream()
                  .anyMatch(r -> r.owner().equals("Bell")));

Java 8 In Action is a great book for learning more on streams and predicates.

You dont need static driver or static methods

You dont need a static driver or static methods in Selenium test automation.

Because they bring more problems than benefits.

Such as breaking encapsulation, making objects mutable and promoting procedural code.

not-sure-why-you-dont-like-static

Enough technical terms, lets talk common sense.

We have a test for a successful user log in:

public class LoginTests {

 private WebDriver driver;
 private final String EMAIL = "test@test.com";
 private final String PASSWORD = "password123";
  
 @Before
 public void setUp() {
   driver = new FirefoxDriver();
 }
  
 @After
 public void tearDown() {
   driver.quit();
 }
  
 @Test
 public void successfulLoginWorks() {
   LoginPage loginPage = new LoginPage(driver);
   loginPage.open();
    
   MainPage mainPage = loginPage.loginAs(EMAIL, PASSWORD);
   assertTrue(mainPage.isUserNameDisplayed() == true);
 }
  
}

 

It uses 2 page objects:

public class LoginPage {

 private final String URL = "http://www.abc.com";
 private final String TITLE = "Login Page";
 private final By EMAIL_ID = By.id("emailId");
 private final By PASSWORD_ID = By.id("passwordId");
 private final By LOGIN_ID = By.id("loginBtnId");

 private WebDriver driver;
 private WebDriverWait wait;

 public LoginPage(WebDriver d) {
   this.driver = d;
   this.wait = new WebDriverWait(this.driver, 30);
 }

 public void open() {
   driver.get(URL);
   if (title().equals(TITLE) == false)
     throw new RuntimeException("Home Page is not displayed!");
 }
  
 public String url() {
   return this.driver.getCurrentUrl();
 }
  
 public String title() {
   return this.driver.getTitle();
 }

 public MainPage loginAs(String username, String password) {
   WebElement emailTextBox = 
   wait.until(visibilityOfElementLocatedBy(EMAIL_ID));
   emailTextBox.sendKeys(username);
    
   WebElement passwordTextBox = 
   wait.until(visibilityOfElementLocatedBy(PASSWORD_ID);
   passwordTextBox.sendKeys(password);
    
   WebElement loginButton = 
   wait.until(visibilityOfElementLocatedBy(LOGIN_ID);
   loginButton.click();
    
   return new MainPage(this.driver);
 }
}

 

And MainPage …..

public class MainPage {
 private final String URL = "http://www.abc.com/main";
 private final By USERNAME_ID = By.id("userNameId");
  
 private WebDriver driver;
 private WebDriverWait wait;

 public MainPage(WebDriver d) {
   this.driver = d;
   this.wait = new WebDriverWait(this.driver, 30);
   if (url().equals(URL) == false)
     throw new RuntimeException("Main Page is not displayed!");
 }

 public String url() {
   return this.driver.getCurrentUrl();
 }
  
 public boolean isUserNameDisplayed() {
   WebElement userNameLabel = 
   wait.until(visibilityOfElementLocatedBy(USERNAME_ID));
   
   return userNameLabel.isDisplayed();
 }

}

 

The test can be improved in 2 places.

First, the driver is passed to the LoginPage object.

Second, we create a LoginPage object in the test.

 

How is the driver used by the page classes?

The test creates a LoginPage object and passes the driver object to it:

LoginPage loginPage = new LoginPage(driver);

 

The LoginPage constructor gets the driver as parameter and saves it in a class field:

public LoginPage(WebDriver d) {
 this.driver = d;

 

LoginPage class passes the driver to a MainPage object in the loginAs() method:

public MainPage loginAs(String username, String password) {
 .......    
 return new MainPage(this.driver);
}

 

The MainPage constructor gets the driver as parameter and saves it in a class field.

The driver object is passed around by the page classes.

 

How can we fix these 2 problems?

One way would be with a static driver and static page methods.

 

exactly-my-point-static-is-the-only-way

 

First, we create a BaseTest class as a parent for test classes.

We move to it the driver object and make it static.

We also move to it the setUp() and tearDown() methods, make them static and change their annotations from @Before and @After to @BeforeClass and @AfterClass:

public class BaseTest {

 public static WebDriver driver;

 @BeforeClass
 public static void setUp() {
   driver = new FirefoxDriver();
 }
  
 @AfterClass
 public static void tearDown() {
   driver.quit();
 }

}

 

Next, we make the LoginTest class inherit from BaseTest and remove the driver object:

public class LoginTests extends BaseTest {
 private final String EMAIL = "test@test.com";
 private final String PASSWORD = "password123";

 @Test
 public void successfulLoginWorks() {
   LoginPage loginPage = new LoginPage();
   loginPage.open();
    
   MainPage mainPage = loginPage.loginAs(EMAIL, PASSWORD);
   assertTrue(mainPage.isUserNameDisplayed() == true);
 }
  
}

 

Notice that there is no driver, setUp() and tearDown() methods in LoginTests.java.

How do the page classes access the static driver?

 

A static import for the BaseTest class is added both to LoginPage and MainPage classes:

import static BaseTest.*;

 

Because of it, since the driver field of BaseTest is public, the page classes can use it as if it is local to the page class.

import static BaseTest.*;

public class LoginPage {

 private final String URL = "http://www.abc.com";
 private final String TITLE = "Login Page";
 private final By EMAIL_ID = By.id("emailId");
 private final By PASSWORD_ID = By.id("passwordId");
 private final By LOGIN_ID = By.id("loginBtnId");

 private WebDriverWait wait = new WebDriverWait(driver, 30);

 public void open() {
   driver.get(URL);
   if (title().equals(TITLE) == false)
     throw new RuntimeException("Home Page is not displayed!");
 }
  
 public String url() {
   return driver.getCurrentUrl();
 }
  
 public String title() {
   return driver.getTitle();
 }

 public MainPage loginAs(String username, String password) {
   WebElement emailTextBox = 
   wait.until(visibilityOfElementLocatedBy(EMAIL_ID));
   emailTextBox.sendKeys(username);
    
   WebElement passwordTextBox = 
   wait.until(visibilityOfElementLocatedBy(PASSWORD_ID);
   passwordTextBox.sendKeys(password);
    
   WebElement loginButton = 
   wait.until(visibilityOfElementLocatedBy(LOGIN_ID);
   loginButton.click();
    
  return new MainPage();
 }
}

 

And MainPage …..

import static BaseTest.*;

public class MainPage {
 private final String URL = "http://www.abc.com/main";
 private final By USERNAME_ID = By.id("userNameId");
  
 public MainPage() {  
   if (url().equals(URL) == false)
     throw new RuntimeException("Main Page is not displayed!");
 }

 public String url() {
   return driver.getCurrentUrl();
 }
  
 public boolean isUserNameDisplayed() {
   WebElement userNameLabel = 
   wait.until(visibilityOfElementLocatedBy(USERNAME_ID));
   return userNameLabel.isDisplayed();
 }

}

 

Notice that there are no driver parameters for the constructors of the page classes.

The driver fields are removed as well.

Every time a page method needs the driver object, it does not prefix it with this any longer since the driver is not a class field.

 

Great, there is no driver in the test!

 

How do we remove the LoginPage object?

We can make all page methods static for both classes.

The public page methods are all declared as static and do not return any objects.

All page fields become static as well.

import static BaseTest.*;

public class LoginPage {
 private static final String URL = "http://www.abc.com";
 private static final String TITLE = "Login Page";
 private static final By EMAIL_ID = By.id("emailId");
 private static final By PASSWORD_ID = By.id("passwordId");
 private static final By LOGIN_ID = By.id("loginBtnId");

 private static WebDriverWait wait = new WebDriverWait(driver, 30);

 public static void open() {
   driver.get(URL);
   if (title().equals(TITLE) == false)
     throw new RuntimeException("Home Page is not displayed!");
 }
  
 public static String url() {
   return driver.getCurrentUrl();
 }
  
 public static String title() {
   return driver.getTitle();
 }

 public static void loginAs(String username, String password) {
   WebElement emailTextBox = 
   wait.until(visibilityOfElementLocatedBy(EMAIL_ID));
   emailTextBox.sendKeys(username);
    
   WebElement passwordTextBox = 
   wait.until(visibilityOfElementLocatedBy(PASSWORD_ID);
   passwordTextBox.sendKeys(password);
    
   WebElement loginButton = 
   wait.until(visibilityOfElementLocatedBy(LOGIN_ID);
   loginButton.click();	
 }
}

 

And MainPage class …

import static BaseTest.*;

public class MainPage {
 private static final String URL = "http://www.abc.com/main";
 private static final By USERNAME_ID = By.id("userNameId");
  
 private static WebDriverWait wait = new WebDriverWait(driver, 30);
  
 public static void open() {
   if (url().equals(URL) == false)
     throw new RuntimeException("Main Page is not displayed!");
 }
  
 public static String url() {
   return driver.getCurrentUrl();
 }
  
 public static boolean isUserNameDisplayed() {
   WebElement userNameLabel = 
   wait.until(visibilityOfElementLocatedBy(USERNAME_ID));
  
   return userNameLabel.isDisplayed();
 }

}

 

Since all methods are static and we dont want any objects in the test, the page methods do not return any objects.

We do not have constructors either.

For the MainPage class, this creates a problem since we were validating in the constructor that the page is displayed.

The loginAs() method does not return a MainPage object too.

To go around all these restrictions, we create an open() method in the MainPage class that does not open the page but validates that it is displayed.

 

How does the test look with static methods?

public class LoginTests extends BaseTest {

 @Test
 public void successfulLoginWorks() {
   LoginPage.open();
   LoginPage.loginAs(EMAIL, PASSWORD);
   MainPage.open();
   assertTrue(MainPage.isUserNameDisplayed() == true);
 }
  
}

 

Very convenient, is it not?

No driver, no LoginPage object, no setUp() and tearDown()!!!

All these are achieved with static methods, static variables and a static driver.

 

yep-you-are-wasting-my-time

 

Is this correct?

I dont think it is.

Lets look first at concerns about the public static driver.

Our driver is a public field of the BaseTest class.

Class fields should always be private so that they cannot be accessed and modified from outside of the class.

It should not be possible to change the fields of a class since this means changing the state of the class’s objects.

This is called immutability in programming meaning that the state of an object should not be changed after the object is created.

Our driver is also static.

Java code should be object oriented so it should use objects.

Each object encapsulates fields and methods and its methods should work on the class fields and the methods parameters only.

Using external static variables in a class means that we break the encapsulation concept.

The state of the object is known when the object’s methods only use the object’s fields.

When external static variables are used as well, the state of the object is not known any longer.

Finally, the static page methods.

Because of using static page methods, all class fields must be static as well.

So the page class uses everything static.

We dont need objects any longer when using static methods.

This is wrong for the same reasons already discussed (immutability, encapsulation).

 

But there is one more reason for not using static variables and methods.
Static methods and variables encourage procedural code to be written instead of object oriented.

 

Now, it seems like we are failing at automation.

It is not too bad to just have a static driver variable.

But using static in other ways is not recommended.

 

static-is-great-you-dont-know-how-to-use-it

So, if static is bad, how do we solve our problems?

First, how important are these problems?

Having the driver passed around by the page classes is not a big deal.

It is a minor case of duplication that is ok to live with.

For the driver in the test and the page object, we can solve this in a different way.

First, we go back to the previous code version where nothing static was used.

Then, we change the BaseTest class by adding a method to open the site:

public class BaseTest {

 private final String URL = "http://www.abc.com";
  
 public WebDriver driver;

 @Before
 public void setUp() {
   driver = new FirefoxDriver();
 }
  
 @After
 public void tearDown() {
   driver.quit();
 }

 public LoginPage openSite() {
   driver.get(URL);
	 
   return new LoginPage(this.driver);
 }
  
}

 

Notice that BaseTest uses non-static methods again and @Before/@After annotations.

The test becomes:

public class LoginTests {

 @Test
 public void successfulLoginWorks() {
   LoginPage loginPage = openSite();
   loginPage.open();
    
   MainPage mainPage = loginPage.loginAs(EMAIL, PASSWORD);
   assertTrue(mainPage.isUserNameDisplayed() == true);
 }
  
}

 

Now, openSite() launches the site and returns the LoginPage object.

The LoginPage object encapsulates the driver and passes it to the MainPage object.

 

i-am-not-convinced-try-again

 


 

If you liked this article,

you may be interested in my new KINDLE book about how to simplify Selenium code with automation patterns:

Improve Selenium Code with Automation Patterns:

Page Object Model ,Page Factory, Page Elements, Base Page, Loadable Component

 

Find child elements with locator chaining

KIT518860_broad_chain_closeup_c_wikimedia.org_[1]

Have you ever had to find an element in another element?

Of course you have.

How did you do it?

 

Maybe you used a locator that searches for the parent element first and then for the child element in the parent.

 

Like in the following test:

public class TestClass {

  private String HOME_URL = "http://www.vpl.ca/";
  private String RESULTS_URL = "vpl.bibliocommons.com/search";

  private By SEARCH_BOX_ID = By.id("edit-search");
  private By SEARCH_BUTTON_ID = By.id("edit-submit");

  private By TITLE_LOCATOR = By.xpath(
    "(//div[contains(@data-js, 'bib-list-item')])[1]" +
    "//span[@class='title']");

  //driver variable, setUp() and tearDown() methods are skipped

  @Test
  public void test1() {
    driver.get(HOME_URL);
    assertEquals(driver.getCurrentUrl(), HOME_URL);

    WebElement searchBox = driver.findElement(SEARCH_BOX_ID);
    searchBox.sendKeys("java");

    WebElement searchButton = driver.findElement(SEARCH_BUTTON_ID);
    searchButton.click();

    assertTrue(driver.getCurrentUrl().contains(RESULTS_URL));

    WebElement title = driver.findElement(TITLE_LOCATOR);
    String titleText = title.getText().toLowerCase();

    assertTrue(titleText.contains("java"));
  }

}

 

In this case, the test opens the site, searches for a keyword and then finds the title of the first result.

The locator of the title includes the locator of the first result:

private final By TITLE_LOCATOR = By.xpath(
   "(//div[contains(@data-js, 'bib-list-item')])[1]" + 
   "//span[@class='title']");

(//div[contains(@data-js, ‘bib-list-item’)])[1]  is the locator of the first result.

//span[@class=’title’] is the locator of the first result’s title.

 

This seems like a decent approach but is it not.

If the code generates an exception when trying to find the title element, is the error about the title not being available or about the first result?

Since the locator combines both, it would be difficult to know.

 

We can change the code so that the parent element is found first and stored in a WebElement variable.

 

The child element is then searched inside of the parent element:

public class TestClass {

  private String HOME_URL = "http://www.vpl.ca/";
  private String RESULTS_URL = "vpl.bibliocommons.com/search";

  private By SEARCH_BOX_ID = By.id("edit-search");
  private By SEARCH_BUTTON_ID = By.id("edit-submit");

  private By RESULT_BOX_XPATH  = By.xpath(
    "(//div[contains(@data-js, 'bib-list-item')])[1]");

  private By TITLE_XPATH = By.xpath(
    ".//span[@class='title']"); 

  //driver variable, setUp() and tearDown() methods are skipped

  @Test
  public void test2() {
    driver.get(HOME_URL);   
    assertEquals(driver.getCurrentUrl(), HOME_URL);

    WebElement searchBox = driver.findElement(SEARCH_BOX_ID);
    searchBox.sendKeys("java"); 

    WebElement searchButton = driver.findElement(SEARCH_BUTTON_ID);
    searchButton.click();

    assertTrue(driver.getCurrentUrl().contains(RESULTS_URL));

    WebElement result = driver.findElement(RESULT_BOX_XPATH);
    WebElement title = result.findElement(TITLE_XPATH);
    String titleText = title.getText().toLowerCase();

    assertTrue(titleText.contains("java"));
  }
}

 

This time, the code finds the result element and stores it in a WebElement variable:

WebElement result = driver.findElement(RESULT_BOX_XPATH);

Then, it searches for the title element inside of the result element:

WebElement title = result.findElement(TITLE_INNER_XPATH);

Notice that the title locator starts with a dot.

TITLE_XPATH = By.xpath(".//span[@class='title']");

This is important when searching an element in another element.

When the code works this way, in case of an error, it is very clear which element caused it.

 

This is better than before but it extends poorly.

What if you need to find an element included in another element included in another element included in another element?

For each parent element, you need to search for the element and store it in a variable.

Which leads to lots of duplication.

This duplication can be removed using the ByChained Selenium class.

See how the code looks now:

public class TestClass {

  private String HOME_URL = "http://www.vpl.ca/";
  private String RESULTS_URL = "vpl.bibliocommons.com/search";

  private By SEARCH_BOX_ID = By.id("edit-search");
  private By SEARCH_BUTTON_ID = By.id("edit-submit");

  private By RESULT_BOX_XPATH  = By.xpath(
    "(//div[contains(@data-js, 'bib-list-item')])[1]");

  //driver variable, setUp() and tearDown() methods are skipped

  private By TITLE_XPATH = By.xpath(".//span[@class='title']");

  @Test
  public void test3() {
    driver.get(HOME_URL);    
    assertEquals(driver.getCurrentUrl(), HOME_URL);

    WebElement searchBox = driver.findElement(SEARCH_BOX_ID);
    searchBox.sendKeys("java");  

    WebElement searchButton = driver.findElement(SEARCH_BUTTON_ID);
    searchButton.click();

    assertTrue(driver.getCurrentUrl().contains(RESULTS_URL));

    WebElement title = driver.findElement(
         new ByChained(RESULT_BOX_XPATH,
                TITLE_XPATH));

    String titleText = title.getText().toLowerCase();

    assertTrue(titleText.contains("java"));
  }  
}

The code to find the title looks rather weird:

WebElement title = driver.findElement(
         new ByChained(RESULT_BOX_XPATH,TITLE_XPATH));

It creates a new object for the ByChained class.

The object gets 2 parameters in the constructor for the locators of the parent and child elements.

Finding the element happens as follows:

  • the element for the 1st locator is searched
  • the element for the 2nd locator is searched in the first element

Using this approach scales well even if we have elements included in many other elements.

There are no additional WebElements that should be created and the code stays approximately the same size.

 


Tips and tricks are great.

Keep coming to this blog for more.

However, if you are interested in better and more detailed learning, this Kindle ebook will help you improve your Selenium code:

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

I am using all these patterns daily and so can you.

Why do static variables and methods suck?

I believe they are very full at times.

I got this comment on a LinkedIn post for the differences between Selenium testers and Selenium developers.

It is worth providing an answer.

Now, I am not a Java expert, far from it.

But others are.

For example, Simon Stewart.

Yes, that Simon Stewart who created Seleniumn WebDriver.

This is from his blog:

“Singletons? Static Methods? Also No.
Singletons (in the traditional “implemented as a static field in a class” sense, not in the “ideally we’d only have one of these” sense) destroy our ability to have fun and write tests that can run in parallel, slashing our potential productivity. Also, it leads people to start using the Service Locator pattern instead of Dependency Injection, and we take DI as an article of faith (see above), mainly because it facilitates TDD by making collaborators clear, like we (also) said above.”

So, static methods? Also no.

Do you need more reasons against static variables and methods?

They promote code that is not object oriented.

 

Object oriented code is about objects.

 

Every method is used on an object.

 

Since static variables or methods are for the class but not the class’s objects, you are writing code that does not use objects.

 

Have a look at the following articles for more details:

Still not convinced?

Read this topic from Stack Overflow.

 

Still in doubt?

Continue to use them.

What are the differences between Selenium testers and Selenium developers?

wir[1]

What follows is inspired from reality.

It is not a product of my imagination.

 

Tester: Selenium is a tool like QTP.

Developer: Selenium is a Java library for web test automation.

 

Tester: I will automate test cases by recording them with Selenium IDE.
Developer: Selenium IDE is not an automation tool.

 

Tester: I dont need to write code like developers. I used to write Visual Basic code and that should be enough for automation.
Developer: The automation code should be at the level of production application code.

 

Tester: Every time my test needs a verification, I do it in IF/ELSE statements.
Developer: Verifications are done with JUNIT or TESTNG assertions.

 

Tester: Who cares if all code is in the test method? It works and it looks good to me.
Developer: I will first write an automation framework.
Then I will create the page object classes that are used in the test methods.

 

Tester: Explicit waits and expected conditions are not reliable and dont work well for me. I have created my own.
Developer: Explicit waits and expected conditions work well. I extend them in custom classes when needed.

 

Tester: Look, my test works! That is all I care about! I can start a new test!
Developer: My test should work but also be easy to understand, short and maintainable.

 

Tester: All my libraries are imported to the project. If I need new versions, I remove the old libraries and import the new ones. I used Maven long time ago and dont remember much about it.
Developer: I use Maven for managing dependencies.

 

Tester: All tests run from my computer every night. I run them anytime someone needs them.
Developer: Anyone can run my tests from Jenkins. They are scheduled to run every night.

 

Tester: My tests run in parallel on my computer.
Developer: My tests run in parallel on all available Jenkins slaves.

 

Tester: I love using static methods and static variables.
Developer: Static sucks. I avoided it as much as possible.

 

Tester: My project is very cool. I have a utility class for all common purpose methods. All page classes inherit from the utility class. This makes my page classes shorter.
Developer: I use composition to break the page classes in page element classes.

 

Tester: All my page element locators are in property text files.
Developer: If the page element locators are outside of the page classes, the class encapsulation is broken.

 

Do you have anything else that should be added to the list?

Please tell in the comments so I can add more.

 


 

Want to be more than a Selenium tester?

Start with this Kindle book on automation patterns that can make your Selenium code better:

Improve Selenium Code with Automation Patterns:

Page Object Model, Page Factory, Page Elements, Base Page, Loadable Component

 

amazon book

 

 

How much Java should you know for a Selenium testing job?

odd-one-out[1]

Selenium tester hiding in the middle of Selenium developers

This is a bad question.

The following are testing jobs:

  • manual testing job
  • functional testing job
  • explorary testing job

 

Since when Selenium has anything in common with manual or functional testing?

Web automation with Selenium WebDriver is not a testing job.

 

Selenium tester does not explain anything about what the job is about.

It is misleading as well since no testing is involved.

When doing web automation with Selenium, you do not

  • create test cases
  • execute test cases
  • explore applications
  • report bugs for your testing
  • map test cases to requirements

 

Instead, you take a user story and implement automated tests for it using Java code and the Selenium WebDriver library.

I said library and not tool or application.

We will come back to the distinction between the library and application.

 

So, there is no such thing as a Selenium testing job.

Test automation with Selenium is a development job.

How much Java should you know for a Selenium development job?

First, you need to be a developer.

 

How much Java should a developer know to do a development job?

In-depth language knowledge (Java, C#, etc).

 

What other skills should the developer have?

Design patterns.

How to create a framework.

How to use an existing framework.

How to document code.

How to use a source control system (GIT, SVN).

How to review code.

How to integrate his code with other developers’ code.

How to use Maven to manage dependencies.

How to use Jenkins for continuous integration.

How to use JUNIT or TESTNG for unit testing.

 

How much Java should a developer know for a Selenium job?

All of the above.

 

But, but, I want to be a Selenium tester.

This cannot be right.

I want to be a tester that uses Selenium.

Tell me what to do.

 

Selenium WebDriver automation is for developers and testers who want to become developers.

Anyone else is just wasting his time with Selenium.

 

One more thing should be said about Selenium WebDriver.

Selenium WebDriver is not an automation tool.

It is not like QTP.
It does not have an IDE.
It does not allow record-and-playback.
It does not create an object repository.

It is instead an automation library.

You cannot use it as is.

You need a lot of other knowledge before you can use.
Programming knowledge.

 

This may be why people talk about Selenium testers.

If Selenium would be a tool, testers should be able to learn it.

They can learn QTP, they can learn SOAP UI.

They should be able to learn Selenium.

But Selenium is not a tool.

It is an automation library.

 


 

Want to become a Selenium developer instead of staying a tester?

I have the right book for you:

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

 

amazon book

How do you recognize a fake Selenium tester? By his code

recognize trees by their fruits

You can recognize a fake Selenium tester by looking at his code.
Look at

  1. how much code he writes in a day
  2. more importantly, look at how good the code is

 

The following code is written by a fake Selenium tester.

 

I have added some comments to explain what the code does.

 

public void sendKeys(String keyword){ 
  //create a web driver wait with a 4 seconds timeout 
  wait = new WebDriverWait(driver, 4);
  try { 
       //wait until the element is visible 
       wait.until(
            ExpectedConditions.visibilityOfElementLocated
                (elementLocator)); 

       //find the element and type the keyword in it 
       driver.findElement(elementLocator).sendKeys(keyword); 
      
       //display information to console about the typed keyword
       System.out.println("Entered keyword: "+ keyword); 
       
       //wait 1 second 
       waitFor(1000); 
  } 
  //if there is an exception while typing the keyword
  catch(RuntimeException e) { 
    //display info to console about trying again
    System.out.println("\ntry again to type keyword:" + keyword); 

    //wait 2 seconds; see below the wait() method 
    wait(); 

    //find the element again and type the keyword
    driver.findElement(elementLocator).sendKeys(keyword); 

    //find the element one more time and type enter 
    sendKeyEnter(); 
  } 
}

public void sendKeyEnter(){ 
  wait.until(
         ExpectedConditions.visibilityOfElementLocated
              (elementLocator)); 
  driver.findElement(elementLocator).sendKeys(Keys.RETURN);
} 

public void wait(){ 
  try { Thread.sleep(2000); 
  } 
  catch (InterruptedException e) { 
     // TODO Auto-generated catch block 
     e.printStackTrace(); 
  }
} 

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

 

Not too bad, you would say.

The code is probably created with the intent of

  • trying to type the text in an element that is displayed slowly
  • if the typing fails because the element is not visible yet, wait a few seconds and try again

 

Lets have a second look:

public void sendKeys(String keyword){
   /* 
      why use such a low timeout?  
      if the page is very slow, 4 seconds will not be sufficient; 
      why is the wait object not declared in the sendKeys() method?  
   */ 
   wait = new WebDriverWait(driver, 4); 
   try { 
       /* 
          the result of the next line is the web element; 
          the web element should be saved in a variable and 
          used in the remaining of the method:

           WebElement element = wait.until(.....); 

          also

          is visibilityOfElementLocated the best expected condition 
          if the intent is to type in the element? 
          how about using elementToBeClickable instead? 
       */ 
       wait.until(
           ExpectedConditions.visibilityOfElementLocated
                              (elementLocator)); 

       /*  
          finding the element again is useless; 
          there is no need to find the element again;  
          it was already found by the previous line; 
          just type into it 
       */ 
       driver.findElement(elementLocator).sendKeys(keyword); 

       /* 
           why display info in the console?  
           first, the console can display limited amount of text; 
           second, how is this info from the console useful 
           if you have 250 test methods? 
       */ 
       System.out.println("Entered keyword: " + keyword); 

       /*  
            why wait for 1 second?  
            why wait at all? 
            why not wait for 2, 3, 4 seconds? 
       */ 
       waitFor(1000); 
   } 
   //if there is an exception 
   catch(RuntimeException e) { 
        //same as above about logging info to console 
        System.out.println("\ntry again to type keyword:" + keyword); 

        /* 
           why wait only for 2 seconds?  
           why not 5?  or 10? 
        */ 
        wait(); 

        /*  find the element again and type the keyword 
        */ 
        driver.findElement(elementLocator).sendKeys(keyword); 

        /* 
            no idea why enter has to be pressed; 
            is the web element part of a form so we have to submit it? 
        */ 
        sendKeyEnter(); 
   } 
}

//on what element is this method typing enter?
public void sendKeyEnter(){ 
   wait.until(
       ExpectedConditions.visibilityOfElementLocated
            (elementLocator)); 
   driver.findElement(elementLocator).sendKeys(Keys.RETURN);
} 

/*  for how long does this method wait? 
    this method is duplicated with the next one; 
*/
public void wait(){ 
    try { 
       Thread.sleep(2000); 
    } 
    catch (InterruptedException e) { 
       // the autogenerated code is not removed
       // TODO Auto-generated catch block 
       e.printStackTrace(); 
    }
} 

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

 

What you just saw is a case of “re-inventing the wheel”.

The code tries to find an web element that is loaded slowly in the page.

 

Selenium WebDriver has already classes that do this such as WebDriverWait and ExpectedConditions.

The same thing can be done with just 3 lines of code:

 

WebElement element = new WebDriverWait(driver, 30).until (
                           elementToBeClickable(elementLocator)); 
element.sendKeys(keyword);

 

How does this work?

The wait object will retry every 500 ms finding the element.
If the element is found and clickable, it is returned so it can be saved in a variable.
Otherwise, the wait object with try again.

Finding the element will be retried until

  • the element is found and is clickabled  or
  • the 30 seconds timeout is up

 

But lets say that we are concerned about stale exceptions or we want more control over the wait times.

Then, we can use FluentWaits:

FluentWait<WebDriver> wait = new FluentWait<WebDriver>(driver)
                        .withTimeout(30, SECONDS)
                        .pollingEvery(2, SECONDS)
                        .ignoring(NoSuchElementException.class)
                        .ignoring(StaleElementReferenceException.class) ;

WebElement element = wait.until (elementToBeClickable(elementLocator)); 

element.sendKeys(keyword);

 

So, do you want to be sure that a Selenium tester is real or fake?

Ask him to show you some of his code.

 

Use a custom driver class instead of utility classes

How can I create my own driver class in Selenium?
When learning test automation, you will want your test methods to be executed in multiple browsers such as Firefox and Chrome.

A Firefox driver is created with the FirefoxDriver class:

WebDriver driver = new FirefoxDriver();

A Chrome driver is created with the ChromeDriver class:

WebDriver driver = new ChromeDriver();

Both driver objects use the WebDriver type but are instantiated by different classes.

Now, you dont want to change the class from FirefoxDriver to ChromeDriver and back every time you want to run the tests in another browser.

Instead, you would like to create the driver based on the browser name:

WebDriver driver = new BrowserDriver(browserName);

How do we do this?

We create a custom driver class that implements the WebDriver interface and overrides its methods.

public final class BrowserDriver implements WebDriver {  

   private WebDriver driver;
   private final String browserName;
   private final int timeout = 30; 
   private final String chromeDriverPath = "./src/chromedriver.exe";  

   public BrowserDriver(String browserName) { 
      this.browserName = browserName; 
      this.driver = createDriver(browserName); 
   }  

   private WebDriver createDriver(String browserName) { 
      if (browserName.toUpperCase().equals("FIREFOX") 
         return firefoxDriver(); 

      if (browserName.toUpperCase().equals("CHROME") 
         return chromeDriver();  

      throw new RuntimeException ("invalid browser name"); 
   } 

   private WebDriver chromeDriver() { 
      if (!new File(chromeDriverPath).exists()) 
        throw new RuntimeException
                    ("chromedriver.exe does not exist!"); 

      try { 
        System.setProperty("webdriver.chrome.driver", 
                           chromeDriverPath); 
        return new ChromeDriver(); 
      } 

      catch (Exception ex) { 
        throw new RuntimeException
              ("couldnt create chrome driver"); 
      } 
   } 

   private WebDriver firefoxDriver() { 
      try { 
         return new FirefoxDriver(); 
      } 
      catch (Exception ex) {         
         throw new RuntimeException
              ("could not create the firefox driver"); 
     } 
   } 

   @Override 
   public String toString() { 
      return this.browserName; 
   } 

   public WebDriver driver() { 
      return this.driver; 
   }  

   @Override 
   public void close() { 
      driver().close();   
   }  

   @Override 
   public WebElement findElement(By locator) { 
      return driver().findElement(locator); 
   }  

   @Override 
   public List findElements(By arg0) { 
      return driver().findElements(arg0); 
   }  

   @Override 
   public void get(String arg0) { 
      driver().get(arg0); 
   }  

   @Override 
   public String getCurrentUrl() { 
      return driver().getCurrentUrl(); 
   }  

   @Override 

   public String getPageSource() { 
      return driver().getPageSource(); 
   }  

   @Override 
   public String getTitle() { 
      return driver().getTitle(); 
   }  

   @Override 
   public String getWindowHandle() { 
      return driver().getWindowHandle(); 
   }  

   @Override 
   public Set getWindowHandles() { 
     return driver().getWindowHandles(); 
   }  

   @Override 
   public Options manage() { 
      return driver().manage(); 
   }  

   @Override 
   public Navigation navigate() { 
      return driver().navigate(); 
   }  

   @Override 
   public void quit() { 
     driver().quit(); 
   }  

   @Override 
   public TargetLocator switchTo() { 
      return driver().switchTo(); 
   }  

   @Override 
   public  X getScreenshotAs(OutputType target
   throws WebDriverException { 
      return ((TakesScreenshot) driver())
                    .getScreenshotAs(target);
   } 

}

 

The only method that is not defined in the WebDriver interface is createDriver().
createDriver() creates a driver object based on the browser name and stores it in the driver variable.

All other methods just override the WebDriver interface methods.

In the test method, you can now use the new BrowserDriver class instead of FirefoxDriver and ChromeDriver:

WebDriver driver = new BrowserDriver(“CHROME”);

driver.get(“http://www.bestbuy.com”);

WebElement searchBox = driver.findElement(searchBoxLocator);

 

The custom driver class can add as well new methods.

 

Lets say that you want to have find element methods that use the WebDriverWait and ExpectedConditions classes:

public WebElement findVisibleElement(By locator) {
   WebElement element = new WebDriverWait(driver(), timeout)
                .until( visibilityOfElementLocated (locator));
   return element;
}

public WebElement findClickableElement(By locator) {
   WebElement element = new WebDriverWait(driver(), timeout)
               .until( elementToBeClickable (locator));
   return element;
}

public WebElement findHiddenElement(By locator) {
   WebElement element = new WebDriverWait(driver(), timeout)
              .until( presenceOfElementLocated (locator));
   return element;
}

You may be tempted to create a utility class, move these methods there and then use the utility class as a parent for the page classes.

Resist this temptation as it leads to bad things 🙂

Avoid utility classes in your automation projects.

More about utility classes very soon on this blog.

Instead of the utility class, you can move these methods to your custom driver class.

public final class BrowserDriver implements WebDriver {  

   private WebDriver driver; 
   private final String browserName; 
   private final int timeout = 30; 
   private final String chromeDriverPath = "./src/chromedriver.exe"; 

   public BrowserDriver(String browserName) { 
      this.browserName = browserName; 
      this.driver = createDriver(browserName); 
   }  

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

   @Override 
   public WebElement findElement(By locator) { 
     WebElement element = new WebDriverWait(driver(), timeout) 
                        .until( visibilityOfElementLocated(locator)); 
     return element; 
   }  

   @Override 
   public List findElements(By arg0) { 
     return driver().findElements(arg0); 
   }

   public WebElement findClickableElement(By locator) { 
      WebElement element = new WebDriverWait(driver(), timeout) 
                       .until( elementToBeClickable(locator)); 
      return element; 
   } 

   public WebElement findHiddenElement(By locator) { 
      WebElement element = new WebDriverWait(driver(), timeout) 
                      .until( presenceOfElementLocated(locator)); 
      return element; 
 }

}

How to retry automatically Selenium tests

Test automation methods fail often.

Sometimes because the test automation code has bugs so you need to fix them.

Other times because the tested site does not load correctly or loads very slowly.

 

Lets look in more detail at this second case.

 

The test automation code is correct.

You prove it correct by running the test multiple times.
If the test method fails a lot (4-5 times out of 10), the problem is in the automation code.
If the test method fails once every 15 or 20 runs, the site is at fault.

 

These rare and random failures are not real failures.

It would be good if we could re-run failed test methods automatically a few times before declaring them as failed.

How can we do this?

Lets start with a simple test class with 3 test methods:

public class TestRetry {

  @Test
  public void testPassed() {
    System.out.println("test passed!");
    assertTrue(true);
  }

  @Test
  public void testFailed() {
    System.out.println("test failed!");
    assertTrue(false);
  }

  @Test
  public void testMayFail() {
    int i = new Random().nextInt(10);
    System.out.println("test may fail! - " + i);
    if (i > 5)
       assertTrue(false);
    else
       assertTrue(true);
  }
}

 

The first method passes all the time.

The second method fails all the time.

The third method fails sometimes.

 

We want to be able to re-run the third test method automatically every time it fails.

 

For this purpose, 2 new classes are created:

  1. RetryAnalyzer (which implements the IRetryAnalyzer TestNG interface)
  2. RetryTestListener (which extends the TestListenerAdapter TestNG class)

 

RetryAnalyzer uses a variable for the current retry count.

It has also a variable for the maximum retry count.

Its retry() method checks if the current retry count is smaller than the max count.

If it is, the current count is increased by 1 and the method returns true.

Otherwise, the method returns false.

 

import org.testng.IRetryAnalyzer;

import org.testng.ITestResult;


public class RetryAnalyzer implements IRetryAnalyzer  { 

  private int count = 0; 

  private int maxCount = 2;

  @Override

  public boolean retry(ITestResult result) { 

    if(count < maxCount) {  

       count++;

       return true;        

    }        

    return false

 }

}

 

The RetryAnalyzer class does not do anything by itself.

It needs to be used with the RetryTestListener class.

 

RetryTestListener overrides the onTestFailure() method so that

  1. when the script fails, the script is retried
  2. if the retry count is less than the max count, the script’s status is changed to skipped
  3. if the retry count is equal to max count, the script fails and the script’s status is failed

 

import org.testng.ITestResult;

import org.testng.Reporter;

import org.testng.TestListenerAdapter;

public class RetryTestListener extends TestListenerAdapter  {

@Override
public void onTestFailure(ITestResult result {

     Reporter.setCurrentTestResult(result);

     if(result.getMethod().getRetryAnalyzer().retry(result))                         result.setStatus(ITestResult.SKIP);

     Reporter.setCurrentTestResult(null);

  }

}

 

The test class can be updated now to use the new classes.

The listener is attached to the test class using the @Listeners annotation.

The third test method is updated by adding the retryAnalyzer attribute to the @Test annotation.

 

import static org.testng.Assert.assertTrue;

import java.util.Random;

import org.testng.annotations.Listeners;

import org.testng.annotations.Test;

@Listeners(RetryTestListener.class)

public class TestRetry {

  @Test

  public void testPassed() {

      System.out.println("test passed!");

      assertTrue(true);

  }

  @Test

  public void testFailed() {

      System.out.println("test failed!");

      assertTrue(false);

  }

  @Test(retryAnalyzer=RetryAnalyzer.class)

  public void testMayFail() {

       int i = new Random().nextInt(10);

       System.out.println("test may fail! - " + i);

       if (i > 5)

             assertTrue(false);

      else

             assertTrue(true);

   }

}

 

If the third method fails, its status is set to SKIPPED and the method is retried.

 

For the first retry, if the method passes, the method’s execution ends with the status PASSED.

If the method fails again, the method’s status is set to SKIPPED and the method is retried (retry count = 1).

 

For the second retry, if the method passes, the method’s ends with the status PASSED.

If the method fails, the method’s status is changed to SKIPPED and the method is retried (retry count = 2).

 

Finally, If the method passes, the method’s ends with the status PASSED.

If the method fails, the method’s status is changed to FAILED.