IntelliJ IDEA: Selenium WebDriver automated web tests with Page Objects in 15 minutes

When I was starting out as a Test Engineer I was overwhelmed with the amount of terminology that you are getting exposed to as a beginner.

Initially, it all seems fun, but once you are getting to the automation part this is where the things might get “scary”. At some point, you even feel like “Is it for me? Can I handle all that?”. Those worries go away with confidence once you start passionately working on your code and see it performing the “fun” stuff.

Many resources sell courses that cost a considerable amount of hard-earned cash. I have nothing against those courses, but in reality, everything is available free or almost free online.

The main problem is to get started quickly without going too much into the details (to avoid losing motivation) and have it all as a single article so that it is easy to digest. Also, it’s a good idea to show how to create test cases as a maintainable structure rather than just a sequence of commands.

For the purpose of this article the environment that we are going to use will be:

IDE: IntelliJ IDEA

Programming language: Java

Browser and OS: Chrome on Mac

Automation Tool: WebDriver + chromedriver

This article has you covered for all those points. Basic knowledge of Java and OOP concepts would be helpful to understand the logic of our tests.

There is also a video tutorial available that you can follow along with this article.

Shall we start?

The Basics

Selenium WebDriver is a tool to automate the execution of manual Web-Browser workflows. It might be either a simple form that you are tired of filling out multiple times or a complex system that verifies hundreds of Web pages.

The idea here is that we are loading a specific webpage(s), performing actions with it, and comparing if results were those that we expected or not. Of course, there are some variations in terms of setting up the environment depending on which platform do we use (e.g Windows, Mac, or Linux).

The typical syntax looks like this:

Getting a URL: driver.get(“[website url]”)

Finding an element: driver.findElement(By.id(“login”))

Sending a key: [element].sendKeys(“[Keys to send]”)

Performing a click: [element].click()

Our plan of action on a webpage comes down to this scenario most of the time:

1. Load a webpage (specific section of the website)
2. Find an element that we want to perform an action on. There are multiple ways to identify an element on a webpage. Those element identifiers are called “locators”. We are going to be examining “XPath” and “id” locators in this article
3. Perform an action with it. Most of the time it involves sending a specific key sequence and/or clicking the element
4. Validate the state. This is where the power of Unit-testing frameworks (e.g TestNG, JUnit) comes handy. We are making sure that the actual result matches the expected result

Our project for Test Automation

We will be automating a simple Web form by typing first and last name and clicking the submit button.

The outlined script would look like this:

1. Type username
2. Type password
3. Press a “Submit” button
4. Verify that the form was successfully submitting by validating the confirmation message

Setting up the project

Everything seems to be clear so far? Alright, then let’s set up the project and our environment.

First, we need to download and install IntelliJ IDEA. You can download it from here. Follow the installation instructions depending on your platform, it should be easy to install. You might also need to update your Java to the latest version.

Once we have it all installed on our local system, let’s open up the application and create a new project.

1. Press “Create a new project”
2. Select “Maven” on the left side and press “Next”

3. Pick any name for the project (e.g “Form Automation”) and press “Finish” to create this project

And after a few moments, we should have a template that we can work with. You might have a question about Maven

Maven is a build automation tool, used primarily for Java projects. We will be using it to add additional libraries to our project

After we create our project and open pom.xml file it will look similar to this:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>Form Automation</artifactId>
    <version>1.0-SNAPSHOT</version>
</project>

Now we can use this file to add additional libraries that we can use to automate our application.

Here are the lines (highlighted in bold) that we should add to our project, so we are able to automate our Web application:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.nomadicdmitry</groupId>
    <artifactId>Form Automation</artifactId>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <dependency>
        <groupId>org.seleniumhq.selenium</groupId>
        <artifactId>selenium-server</artifactId>
        <version>3.141.59</version>
    </dependency>
    <dependency>
        <groupId>org.testng</groupId>
        <artifactId>testng</artifactId>
        <version>7.1.0</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.0.0-M4</version>
    </dependency>
    </dependencies>
</project>

Once we add those lines, we have almost all necessary libraries that we will use in our project. To be specific:

Selenium Webdriver: org.seleniumhq.selenium
TestNG (unit testing framework): org.testng
Maven SureFire (easy test plan execution): org.apache.maven.plugins

A couple more things to note:

1. After adding those libraries make sure to press the button on the right side to download those libraries (the one with the “M” symbol). You should see it starts downloading those libraries
2. Make sure to check the latest versions of those libraries to avoid any problems further down the road. Here is a link to Maven repository for Selenium. You can easily search necessary library and add the proper version to your project

We are ready to start writing the code. However, let’s first draft it out and then proceed.

Drafting up the code

Typically, most of the WebDriver tutorials describe the sequence of commands that we need to execute. Let’s follow this pattern for a moment and outline what actions we are performing here for our test:

System.setProperty("webdriver.chrome.driver", "chromedriver");

WebDriver driver = new ChromeDriver();

driver.get(https://formy-project.herokuapp.com/form);
driver.findElement(By.id("first-name")).sendKeys("First Name");
driver.findElement(By.id("last-name")).sendKeys("Last Name");
driver.findElement(By.xpath("//a[contains(text(),'Submit')]")).click();
driver.close();

That’s it! Seven lines of code to have a working solution for automating a web form. To clarify, the first line shows the location to a chromedriver (since we are executing this script on Chrome) and the second line creates an instance of WebDriver that we work with later on.

The next lines are easy to analyze since we just load the page and performing actions with locators. This code will work and perform the necessary actions (except the assertion part that we discuss later on).

However, what is the problem with this code? The problem is that it’s nowhere near how it would be used in the real environment and the reasons for that are:

1. It’s not reusable and brings repetitive code if we decide to use it in other places
2. It’s hard to maintain (imaging changing locators for each line if we call those locators multiple times)
3. Eventually it will be hard to read and understand once more tests are added

Let’s get back to our project and plan the project structure.

Creating the project structure

We are going to use a PageObject approach as a basis to design our tests. Essentially, in terms of Java Classes it means that we will create a class for each website page and outline locators and methods to perform actions to this class. Also, there would be one “parent” class that we will be inheriting our objects (pages) from.

Additionally, we would need a class that wires up all classes together and has the variables to store our configuration settings.

Here is how our project structure would look like:

PageObject

TestPlan

Utils

WebForm

Let’s go ahead and create those four classes in our project. Go ahead and open “[project]\src\test\” and right click on “test” folder. Select “New -> Java Class” and create those classes accordingly.

Writing code for Test Classes

Let’s first write the code for the PageObject class. Here is how it will look like:

// All Test Pages are inheriting from this class

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.PageFactory;

public class PageObject {
    protected WebDriver driver;

    public PageObject(WebDriver driver){
        this.driver = driver;
        PageFactory.initElements(driver, this);
    }
}

What is this code for? Well, it simplifies unnecessary code that we would have duplicated in each of our pages otherwise. We are using a PageFactory approach here that extends the PageObject model. As the name suggests, PageFactory allows us to create test pages with the same mechanism behind it. This way, we don’t need to write WebDriver initialization code for each of our pages.

Next, we need to work on our Utils class. This is where we will add information about the parameters of our tests and “helper” methods to avoid a repeatable code.

// Configuration class for Form Automation project

public class Utils {
    final static String BASE_URL = "https://formy-project.herokuapp.com/form";
    final static String CHROME_DRIVER_LOCATION = "chromedriver";
}

It should be easy to understand what this code does. We are simply creating two variables for us to integrate those later:

BASE_URL: Defines a URL that we will work on

CHROME_DRIVER_LOCATION: Path to a chromedriver

Why do we need chromedriver? So, we already have a WebDriver, but that’s not enough for our tests to function. We also need to download a binary of chromedriver, so that our tests will work properly on a specific browser and platform.

In this case, it’s Chrome. Please download the binary from the official website for your platform and place it in the location that you have specified in CHROME_DRIVER_LOCATION. For simplicity, in this example, I just copied it in the root project directory.

Important: Please make sure that your browser version and platform matches the version of the chromedriver. If those are mismatching then your tests will not work.

We are ready to work on our WebForm class which is going to have locators and methods for working with our specific page.

// Page URL: https://formy-project.herokuapp.com/form

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;

public class WebForm extends PageObject{

    private final String FIRST_NAME = "First Name";
    private final String LAST_NAME = "Last Name";

    @FindBy(id = "first-name")
    private WebElement first_name;

    @FindBy(id = "last-name")
    private WebElement last_name;

    @FindBy(xpath = "//a[contains(text(),'Submit')]")
    private WebElement submit_button;

    public WebForm(WebDriver driver) {
        super(driver);
    }

    public void enterFirstName(){
        this.first_name.sendKeys(FIRST_NAME);
    }

    public void enterLastName(){
        this.last_name.sendKeys(LAST_NAME);
    }

    public void pressSubmitButton(){
        this.submit_button.click();
    }
}

Can you see the direction our code is going here? We are breaking up our code in multiple easily reusable blocks. The main benefit here is that our code becomes much more maintainable.

Now we have a PageObject skeleton, Utils class and locators and methods in WebForm class. The next step is to writing up the code to connect everything together. Let’s write our TestPlan class:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterSuite;
import org.testng.annotations.BeforeSuite;
import org.testng.annotations.Test;

public class TestPlan {
    private static final WebDriver driver = new ChromeDriver();

    @BeforeSuite
    public static void main(String[] args) {
        // ChromeDriver location set up in Utils class
            System.setProperty("webdriver.chrome.driver", Utils.CHROME_DRIVER_LOCATION);
    }

    @Test(testName = "Submit a WebForm")
    public static void submitForm(){
        driver.get(Utils.BASE_URL);
        WebForm webForm = new WebForm(driver);
        webForm.enterFirstName();
        webForm.enterLastName();
        webForm.pressSubmitButton();
    }

    @AfterSuite
    public static void cleanUp(){
        driver.manage().deleteAllCookies();
        driver.close();
    }
}

Could you see how our code works now? Here is what we perform here:

1. We are creating a new ChromeDriver instance to use in multiple methods
2. We are setting up the chromedriver property to set up the chromedriver location
3. We are using BeforeSuite, AfterSuite, and Test annotations to structure our tests. Those are annotations of the TestNG framework and allow us to mark each test as a set of executable blocks
4. We are creating a new method to perform a code submission in ”submitForm()” method
5. Afterward, we are loading a URL specified in Utils.BASE_URL which is our configuration class. If we decide to change a URL, we can just modify it there and it will be applied to our tests
6. Next, we create an instance of WebForm class. This is where we perform methods with our WebForm as we outlined in the class itself. If needed, you can scroll up and see those methods described there. Now it looks like a defined set of instructions that is easy to modify if necessary
7. After we are done with everything, we clear the cookies and close the instance of the driver. That’s it, our test is ready

Here comes the most interesting part: executing our test. Hover over the green “play” button on the left and press “Run Test”. This button allows executing individual tests marked with a “Test” annotation.

The Chrome browser should start and perform our test. After it finished, we should see a result at the bottom left:

As we can see here it shows that those tests have passed and execution time on the right side. We have made our test code easier now, but we should also discuss a couple more things: Locators and Test Validation.

Web page Locators

We are using three locators in our application. Those are specified in WebForm class since it belongs to this page:

// Page URL: https://formy-project.herokuapp.com/form

@FindBy(id = "first-name")

@FindBy(id = "last-name")

@FindBy(xpath = "//a[contains(text(),'Submit')]")

As we discussed earlier, we are using ID and Xpath types of locators here. ID is a more preferable way of identifying the elements on the HTML page, but IDs are not always assigned to objects and in those cases, we need to be more creative in terms of locating the element. Let’s talk about locating an element for a “First Name” field.

We should go to this URL in Chrome, right-click and select the “Inspect” option to see this dialog at the bottom.

We can see that this field will be highlighted with a “first-name” specified as an ID locator. This way, we can identify our unique element name.

As you can also see, if you right-click on this field you will have a “Copy” option there which has another locator available which is “XPath”. You can use either absolute (full) or relative XPath. If you take a look at it, the full XPath for a “first name” field will look like this:

/html/body/div/form/div/div[1]/input

As you can see, it indicated the full path to an element in the HTML markup structure. The main problem with using the full XPath is that if something changes on that page (e.g button is shifted to another place) our code will not operate anymore.

That’s why for our “Submit” button automation case we are using relative XPath structure:

//a[contains(text(),'Submit')]

In this scenario, we only rely on the identifier text which is “Submit”. It still might stop working in case the button get renamed, but at least there is a bit less room for an error.

Ideally, it should be something unique that never or rarely changes. You don’t want to be re-write your test code every week, right?

Here is one more tool for you to explore which is called Selenium IDE. It’s a Chrome browser extension. It allows you to “record” your interactions with any website and then play it back easily. It also shows any locators it used and you can adjust it accordingly.

You can also export those Selenium IDE actions to actual code. The only problem is that it will not be very maintainable, so it’s mainly useful for drafting up your tests.

Test Validation

We have our tests executing and everything passes. Is our goal achieved? It depends on the goal, of course. If our job was to only verify that buttons appear and we can click on those — then we achieved this goal.

However, what if we also want to make sure that the success message is displayed. How we handle the scenario, then?

Let’s open our WebForm class and add a new locator there and a variable to store it:

@FindBy(xpath = "//div[contains(text(),'The form was successfully submitted!')]")
private WebElement alertSuccess;

Great, we are checking if such text exists our page is loaded. Next, let’s add a corresponding method in the same class, like we did before:

public void verifyAlertSuccess(){
    this.alertSuccess.isDisplayed();
}

We have all the verification logic in place now and we are ready to use this method in our TestPlan class, so our final test will look like this now:

@Test(testName = "Submit a WebForm")
public static void submitForm(){
    driver.get(Utils.BASE_URL);
    WebForm webForm = new WebForm(driver);
    webForm.enterFirstName();
    webForm.enterLastName();
    webForm.pressSubmitButton();
    driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
    webForm.verifyAlertSuccess();
}

As you can see, nothing complicated there. I should clarify the timeouts() method that we are using here. Timeouts are necessary part of the test automation. There are multiple timeout methods available, but in this case we are using a simple ImplicitWait approach. It allows us to wait a specified amount of time before our test “gives up” waiting for an element to appear.

We can press the green “play” button again and our test will run once again. This time, it will also check that the specified message appeared. If some other message appears then the test will fail.

Conclusion

I hope that this article was useful for you and you have discovered the basics of WebDriver + ChromeDriver testing. We also talked about the importance of using a PageObject/PageFactory model to build complex test solutions.

We will be discussing more topics in the future, such as:

1. Parametrizing our tests. Sometimes we need to set specific parameters for our tests depending on the requirements. That’s where parametrization comes handy
2. Using Maven SureFire for setting up our test execution sequence through XML
3. Taking screenshots of failed test scenarios. It’s always a good idea to have evidence of failed tests to know the point when those fail. Screenshots give us immediate visual feedback on what has happened
4. Using report creation tools such as Allure to generate meaningful reports
5. Learning more about TestNG assertions. Assertions are a powerful Unit-testing tool that QA Engineers should be able to use

Thank you for reading and stay tuned for more Web-testing related articles. Happy testing!