Test Automation Framework (Selenium with Java) — Stepping Stones or Selenium Foundations Revisited

S01E04 of the Test Automation Framework series about everything you’ll need to set up the nice, simple, yet sophisticated framework.

Covered with clear explanations and pretty illustrations.

Sounds like fun? Cool. Now, please, fasten your seatbelts because you’re here for a ride.

S01E01 — What To Automate?

S01E02 — Test Automation Environment and Tools

S01E03 — The First Selenium Test Case

S01E05 — Page Factory and Elements Related Exceptions

S01E06 — Page Loading Strategies and Waits

S01E07 — Translating JIRA with Selenide (with Exercises)

S01E08 — JIRA, Selenide, Complex SQL, Java Objects with Equals & HashCode (with Exercises)

S01E09 — Code Review and Refactoring (Part 1)

S01E10 — Code Review and Refactoring (Part 2)

S01E11 — Allure in Action

This part of the article is entirely optional — if you already know how to handle the WebDriver configuration, or in case you don’t find it important at the moment, please move straight to the Stepping Stones of Test Framework section.

To automate the browser’s behavior, you have to download and configure the WebDriver. In the previous article, we’ve created our First Selenium Test Case, and we’ve used the WebDriverManager to set up the WebDriver.

WebDriverManager is a great tool, as it can save you a lot of time. However, I would like you to understand what’s happening in the background, thus we’re going to create our own, much simpler version, of the WebDriverManager.

Below you can find the table with an overview of the available WebDrivers (download URLs can be found at the Sources listing on the bottom of this article).

Excerpt from the Selenium Documentation > Installing browser drivers > Quick reference

We’re going to create a simple Chrome WebDriver Configuration Helper (it’s up to you if you’d like to expand this idea later and create your version of the WebDriverManager or would you rather use the existing one).

(Codebase for this guide can be found at: https://github.com/n4bik/test-automation-framework/tree/Awakening)

1 — Download the Chrome WebDriver for every platform available (Windows, Linux & macOS (both Intel and M1)). The version has to be the same as the version of the Chrome browser on your local machine. The first value before the separator is the most crucial (e.g., 95.0.4638.17 will work with the 95.0.4638.54).

2 — Create a new folder in the Test Automation Framework root directory and name it drivers

3 — Unpack and put every WebDriver into the drivers folder

4 — Inside the test package (in my case it’s pl.tomaszbuga) create a new package called engine (or however you’d like; e.g., driver; webdriver)

5 — Inside the engine package create a new Java Class and name it ChromeDriverHelper

6 — Copy and paste the code snippet below to the ChromeDriverHelper class (I’ve made some comments in the code, where the code was not self-explanatory enough, at least for my taste)

7 — Replace the lines:

Line 3:

replace with:

Line 20:

replace with:

8 — Run the test and verify that your brand new ChromeDriverHelper is working fine

In case you’ve skipped the Atom Heart Mother section — please go ahead to the Test Automation Framework — Two Stepping Stones paragraph.

In case you have done the steps mentioned in the Atom Heart Mother section — please remove the entire drivers directory, engine package and replace the lines below in the FirstTest.java file. ChromeDriverHelper was just an example to introduce you to the concept of the WebDriverManager.

Line 3:

replace with:

Line 20:

replace with:

Test Automation Framework — Two Stepping Stones

(Codebase for this guide can be found at: https://github.com/n4bik/test-automation-framework/tree/Awakening)

The most basic parts of a modern Java/Selenium Test Automation Framework are BaseTest and BasePage classes. Both of them are going to be an Abstract class type. Here’s an excerpt from Java Docs regarding what Abstract class is:

An abstract class is a class that is declared abstract—it may or may not include abstract methods. Abstract classes cannot be instantiated, but they can be subclassed.

If you’re somewhat familiar with Java, you might ask “why not use an Interface instead of an Abstract class, then?”. Here’s a Java Docs answer to that question:

Abstract classes are similar to interfaces. You cannot instantiate them, and they may contain a mix of methods declared with or without an implementation. However, with abstract classes, you can declare fields that are not static and final, and define public, protected, and private concrete methods. With interfaces, all fields are automatically public, static, and final, and all methods that you declare or define (as default methods) are public. In addition, you can extend only one class, whether or not it is abstract, whereas you can implement any number of interfaces.

That’s enough theory for now. Let’s focus on the purpose of both BaseTest and BasePage. Below you can find an illustration of what are we going to create in this episode of the Test Automation Framework.

Implementing Apache’s Log4j 2

Before anything else, I would like to implement a simple logging mechanism, so that we don’t have to worry about that later. We’re going to use Apache’s Log4j 2, as our logging library, so let’s implement it right away.

1 — First of all we need to add two dependencies to our pom.xml (Learn more: https://logging.apache.org/log4j/2.x/maven-artifacts.html). We can reuse the version via properties to keep the file tidy.

2 —Remove everything from your FirstTest.java file, but leave empty firstMethod(), so that it looks like on the picture below:

3 — Add a logger to your code with the code below and import Logger & LogManager from org.apache.logging.log4j

4 — Add three logger methods: info, warn, and error and run the FirstTest

5 — As you can see, only the error level is being displayed in our logs. That’s the default, out-of-the-box behavior of the Log4j 2.

Anyhow, we have to change that, because we want to log every action our Test Framework will perform (e.g., “Entering login”, “Entering password”, “Clicking submit button” etc.).

6 — Create a new directory in the src/test called resources

7 — Create a new file in the resources folder and name it log4j2.xml

You can learn more about XML Log4j 2 configuration here: https://logging.apache.org/log4j/2.x/manual/configuration.html#XML

8 — Now rerun the FirstTest and verify that all the info, warn, and error messages are being displayed

Implementing BaseTest

Once, we have logging configured — we can proceed with our BaseTest. Below you can find a recap, of what we’ll be doing.

1 — Create a new package and name it tests

2 — Within the tests package create a new Java class called BaseTest

3 — Move the FirstTest.java file to the tests package

4 — Rewrite the FirstTest, so it extends BaseTest class

5 — Copy the code from below, paste it in the BaseTest class, and import every required package

Disclaimer: After research, I’ve made for S01E06 — Page Loading Strategies and Waits I have to point out that usage of the ImplictWait is not recommended, as it can act unexpectedly (especially when mixed with ExplicitWait). Please skip the following lines to prepare a fully functional (they’re commented out in the BaseTest code) Test Automation Framework.

6 — Refactor FirstTest.firstMethod() — with the uppercase LOGGER reference (it’s uppercase, because of the final modifier; more on this topic: https://stackoverflow.com/questions/7259687/java-naming-convention-for-static-final-variables)

7 — Rerun the FirstTest and validate that it’s passing (it should open Chrome browser and close it without performing any actions in it)

Implementing BasePage

I get it — you’re tired, but it’s the last part I promise. Anyhow, in case you forgot — this is what we want to build:

Looks easy, right? We even have that Logger part in our BaseTest, so we only have to create a new package (for the sake of maintainability), a new class with Logger and Constructor in it. Also, this is a kind of an important thing, as we’re going to implement yet another POM, but this time it is an abbreviation for a Page Object Model.

1 — Create a new package inside src/test/java/pl.tomaszbuga and name it pom (as short for Page Object Model)

2 — Create a new Java class titled BasePage

3 — Copy the code from the below and paste it inside the BasePage.java

That’s it! Now you’ve got the foundations for creating an awesome Test Automation Framework. In the next episode, we’re going to cover how to implement the Page Object Model on an actual web application and we’re going to automate the Login process to the Ultimate Stack Developer.

  • We’ve covered WebDriver configuration basics (or not, if you skipped that part)
  • We’ve implemented Apache’s Log4j 2
  • We’ve created a BaseTest with the TestNG’s BeforeMethod & AfterMethod annotations
  • At last, we’ve created BasePage to be implemented in the next episode as a fully working Page Object Model

In case of any questions (I believe there can be one or two of those) — feel free to post them in the comments section below.

All the best,

Tomasz Buga, SDET



GitHub Repository available at: https://github.com/n4bik/test-automation-framework/tree/SteppingStones

Chrome/Chromium WebDriver download: https://chromedriver.storage.googleapis.com/index.html

Firefox WebDriver download: https://github.com/mozilla/geckodriver/releases

Edge WebDriver download: https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/

Internet Explorer WebDriver download: https://www.selenium.dev/downloads

Opera WebDriver download: https://github.com/operasoftware/operachromiumdriver/releases


All illustrations made by Tomasz Buga



Software Development Engineer in Tests. Passionate about programming. Experienced, former employee of the insurance industry. Graphic designer by choice.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tomasz Buga

Tomasz Buga


Software Development Engineer in Tests. Passionate about programming. Experienced, former employee of the insurance industry. Graphic designer by choice.