1. Introduction
In this article, we will build on the previous writeup and continue to improve our Selenium/WebDriver testing by introducing the Page Object pattern.
2. Adding Selenium
Let’s add a new dependency to our project to write simpler, more readable assertions:
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.3</version>
</dependency>
The latest version can be found in the Maven Central Repository.
2.1. Additional Methods
In the first part of the series, we used a few additional utility methods, which we’re going to be using here as well.
We’ll start with the navigateTo(String url) method – which will help us navigate through different pages of the application:
public void navigateTo(String url) {
driver.navigate().to(url);
}
Then, the clickElement(WebElement element) – as the name implies – will take care of performing the click action on a specified element:
public void clickElement(WebElement element) {
element.click();
}
3. Page Object Pattern
Selenium gives us a lot of powerful, low-level APIs we can use to interact with the HTML page.
However, as the complexity of our tests grows, interacting with the low-level, raw elements of the DOM is not ideal. Our code will be harder to change, may break after small UI changes, and will be, simply put, less flexible.
Instead, we can utilize simple encapsulation and move these low-level details into a page object.
Before we start writing our first-page object, it’s good to have a clear understanding of the pattern – as it should allow us to emulate a user’s interaction with our application.
The page object will behave as a sort of interface that will encapsulate the details of our pages or elements and will expose a high-level API to interact with that element or page.
As such, an important detail is to provide descriptive names for our methods (ex. clickButton(), navigateTo()), as it would be easier for us to replicate an action taken by the user and will generally lead to a better API when we’re chaining steps together.
Ok, so now, let’s go ahead and create our page object – in this case, our home page:
public class BaeldungHomePage {
private SeleniumConfig config;
@FindBy(css = ".nav--logo_mobile")
private WebElement title;
@FindBy(css = ".menu-start-here > a")
private WebElement startHere;
// ...
public StartHerePage clickOnStartHere() {
config.clickElement(startHere);
StartHerePage startHerePage = new StartHerePage(config);
PageFactory.initElements(config.getDriver(), startHerePage);
return startHerePage;
}
}
Notice how our implementation is dealing with the low-level details of the DOM and exposing a nice, high-level API.
For example, the @FindBy annotation allows us to pre-populate our WebElements; this can also be represented using the By API:
private WebElement title = By.cssSelector(".header--menu > a");
Of course, both are valid; however, using annotations is a bit cleaner.
Also, notice the chaining – our clickOnStartHere() method returns a StartHerePage object – where we can continue the interaction:
public class StartHerePage {
// Includes a SeleniumConfig attribute
@FindBy(css = ".page-title")
private WebElement title;
// constructor
public String getPageTitle() {
return title.getText();
}
}
Let’s write a quick test, where we simply navigate to the page and check one of the elements:
@Test
public void givenHomePage_whenNavigate_thenShouldBeInStartHere() {
homePage.navigate();
StartHerePage startHerePage = homePage.clickOnStartHere();
assertThat(startHerePage.getPageTitle(), is("Start Here"));
}
It’s important to take into account that our homepage has the responsibility of:
- Based on the given browser configuration, navigate to the page.
- Once there, validate the content of the page (in this case, the title).
Our test is very straightforward; we navigate to the home page, execute click on the “Start Here” element, which will take us to the page with the same name, and finally, we just validate the title is present.
After our tests run, the close() method will be executed, and our browser should be closed automatically.
3.1. Separating Concerns
Another possibility that we can take into consideration might be separating concerns (even more) by having two separate classes; one will take care of having all attributes (WebElement or By) of our page:
public class BaeldungAboutPage {
@FindBy(css = ".page-header > h1")
public static WebElement title;
}
The other will take care of having all the implementation of the functionality we want to test:
public class BaeldungAbout {
private SeleniumConfig config;
public BaeldungAbout(SeleniumConfig config) {
this.config = config;
PageFactory.initElements(config.getDriver(), BaeldungAboutPage.class);
}
// navigate and getTitle methods
}
If we are using attributes as By and not using the annotation feature, it is recommended to add a private constructor in our page class to prevent it from being instantiated.
It’s important to mention that we need to pass the class that contains the annotations, in this case, the BaeldungAboutPage class, in contrast to what we did in our previous example by passing this keyword.
@Test
public void givenAboutPage_whenNavigate_thenTitleMatch() {
about.navigateTo();
assertThat(about.getPageTitle(), is("About Baeldung"));
}
Notice how we can now keep all the internal details of interacting with our page in the implementation, and here, we can actually use this client at a high, readable level.
4. Conclusion
In this quick tutorial, we focused on improving our usage of Selenium/WebDriver with the help of the Page-Object Pattern. We went through different examples and implementations to see the practical ways of utilizing the pattern to interact with our site.
As always, the implementation of all of these examples and snippets can be found on GitHub. This is a Maven-based project, so it should be easy to import and run.