Test Automation Framework (Selenium with Java) — Awakening or the First Selenium Test Case

S01E03 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

S01E04 — Selenium Foundations Revisited

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

First of all — what is Maven? Referring to the official website:

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting and documentation from a central piece of information.

What does it mean in reality? It’s a one-file — pom.xml — that makes it simple to build your project (which means your app’s version, title, description, dependencies, and their versions, etc.).

So, for instance — you are the new employee at the Hoax Company Inc., and you’re onboarding. Despite all the coaching, safety training, and bureaucracy — you need to set up the Java Test Project to start providing value to your company.

You’ve got your brand new MacBook and your buddy (a person designated to personally take care of the new employee’s onboarding) tells you that you have to install all the 100 *.jar files that are being used to run the Java Test Project. Also, there are multiple available versions, so you have to follow the data from an Excel sheet and download exactly the version mentioned there so that the project will build successfully. Sounds like a lot of work, ain’t it?

But this is just a story I’ve come up with. In a real-world we use the build automation tools for this (e.g., Ant, Maven, or Gradle).

That’s, basically, one of Maven’s purposes — it helps you to manage all crucial project information (regarding builds, reports, and documentation) within only one file, that uses XML (eXtensible Markup Language) that has quite an easy-to-follow structure. We’re going to cover the main parts of the pom.xml in the next section, and now — let’s focus on creating a new Maven Project within IntelliJ IDEA.

1 — Open the IntelliJ IDEA and click on the New Project button

2 —Select Maven from the menu on the left. Project SDK should be set to the 11, if it’s not — make sure that you have installed Java JDK 11 on your machine

3 — Here’s the part that is usually skipped in most of the tutorials, but I would like to ask you to fill in details regarding your project, as it’s your work and it should be treated with respect.

Name: your-project-name

Location: location/of/your/project/on/your/computer

Artifact Coordinates: details regarding your project, that can be modified later in the pom.xml file

  • GroupId: In case you’re not working for any company at the moment, feel free to add your country code and your name and last name, as this looks professional
  • ArtifactId: Usually your project name (this would be useful in case you’d like to upload your project to the Maven Repository). (Learn more: https://www.jetbrains.com/help/idea/add-a-gradle-library-to-the-maven-repository.html#publish_remote)
  • Version: This is self-explanatory, but I will say it — it defines your app’s version (you can change it from within pom.xml file later)

4 — Click Finish and wait until everything is loaded and indexed.

At this point, you should’ve everything loaded and ready. And your screen probably will look similar to this:

Let’s get an overview of what’s inside the pom.xml, shall we?

Line 1: File’s XML version (1.0 or 1.1) and encoding (https://www.w3.org/TR/xml/#charencoding).

Lines 2–4: determine so-called namespaces which are a broad topic and not relevant for this article. (Learn more: https://www.w3.org/TR/xml-names/)

Line 5: determines the model version of the Project Object Model (it’s related directly to the Maven version; you can find more about this topic in this StackOverflow’s thread: https://stackoverflow.com/questions/19759338/why-modelversion-of-pom-xml-is-necessary-and-always-set-to-4-0-0)

Lines 7–9: Are described in Step 3 from the previous section of this article.

Lines 11–14: Properties are probably one of my favorites — it enables you to manage versions of the particular dependencies and/or variables, from one place in the file. In this basic pom.xml file we have set the bare minimum, which is the Java JDK and its 11th version. To invoke those properties anywhere in the pom.xml you can use the ${your.variable} syntax (e.g., ${maven.compiler.source} will return 11)

README file is one of the most crucial files in the entire codebase (at least from my perspective).

  • It’s accessible for every developer on the team
  • It’s written with a Markdown Markup Language, so it’s easily readable and structured (https://www.markdownguide.org/getting-started/)
  • It comes with the codebase, so there is no need to search the web for the proper documentation site
  • It contains the most important information written down by the actual developers working on the code

Here’s a live example of how I like to structure README files: https://github.com/n4bik/test-automation-framework

And below you can find a detailed explanation, of what’s what and why.

First of all — introduce the Project/Repository and give yourself a credit, so anyone can easily get in touch with you and help you out (if it’s an Open Source Software) or even offer you a job position. Just keep it concise and relevant, like your contact details, website, blog, GitHub, LinkedIn, LeetCode, but maybe stay away from your Instagram account, though.

Then write a little description of the Project — what is it about?; what is its purpose?; where can one’s find any more detailed pieces of information?

Also, I like to present what technologies are being used within the Project (this is most useful when you’re looking for a job, and that’s how you can quickly scrape all your repositories to get your tech stack for the resume) — that’s maybe a good idea for how to apply Selenium to automate something useful… just sayin’.

Key Files Description is my idea on how to keep everyone on the same page. I tend to write down descriptions of the common files that are crucial to successfully build and/or deploy the app (e.g., pom.xml, Dockerfile, some YAML files related to CI/CD services, etc.).

The getting started part should be an element of each README file, period. It’s a part of the manual where you should have instructions on what to download, what to install, and what to do to get the app up and running.

You can start with the Prerequisites where you should describe the technologies (with URL to download pages/docs) that are required to be set up before running the application.

And at last, you should write the manual on how to use the repository to run your app (like the example above).

Remember, that a good README file is a product of The Three Virtues of a GREAT Programmer (https://betterprogramming.pub/here-are-the-three-virtues-of-good-programmers-e561e061ea19)

TestNG is a testing framework inspired from JUnit and NUnit but introducing some new functionalities that make it more powerful and easier to use (…)

That’s what official TestNG’s website says.

But, let’s see how to use TestNG for our Java/Selenium framework. Firstly, let’s create a testng.xml file in the root folder. (Learn more: https://testng.org/doc/documentation-main.html#testng-xml)

I’ve modified the example from the TestNG’s documentation page (code snippet above), but as it’s shown on the picture — the class is called pl.tomaszbuga.FirstTest is indicated with the red highlight. Red highlight in the IntelliJ IDEA is usually a bad sign. In this particular case, it means that there is no class FirstTest in the package named pl.tomaszbuga.

Fortunately, the solution is simple — we just have to create that package and the Test class. Here’s a step-by-step guide, how to achieve that:

1 — Expand the src/test/java path on the menu on the left side

2 — Right-click on the java folder and select New > Package

3 — Type in the name of the package that would correspond to your GroupId from the pom.xml file & hit the Return/Enter key on the keyboard

4 — Right-click on the recently created package on the menu on the left side and select New > Java Class

5 — Enter the name of the class, in my case it will be the FirstTest

6 — Verify that the testng.xml file is now all-green

Once we have the testng.xml file all set up with the most basic configuration (according to the https://testng.org/doc/documentation-main.html#testng-xml), we have to add the TestNG dependency to the pom.xml file, so that we can use it in our framework.

We’re almost there, just stay with me. It’s the last step before writing the first Test Case in Selenium.

As I mentioned earlier there is the thing called Global Maven Repository. We’re going to use that to download TestNG and Selenium for our Test Automation Framework. There is more than one Repository, but we can search through all of them via: https://mvnrepository.com/

As you can see there is GroupId visible (which is org.testng) and ArtifactId (which is testng). After clicking on the result title, we will be redirected to the Version select page. By the way — there you have all of the Artifact Coordinates, from the first section of this article, in one place.

Click on the latest version (for the time being this would be 7.4.0) which should redirect you to the page with pre-generated dependencies for the automation build tool of your choice (we’ll use the Maven, obviously).

Deselect the checkbox from the bottom (that says: Include comment with a link to declaration) and click on the code to copy it to the clipboard.

Go to your pom.xml file within IntelliJ IDEA and paste the code in there.

Oh noes, the dependency tag has the red underline!

That’s because we have to add one more tag which would contain all the dependencies — it’s called <dependencies></dependencies> and should be implemented like this:

Now, the error should be gone. Please repeat the above steps to add Selenium-Java (latest version is 4.0.0) & WebDriverManager (latest version is 5.0.3) dependencies to pom.xml, so that the file looks similar to this (I’ve also used the properties to manage the versions from one place):

Or, if you’re lazy like me — you can copy the entire pom.xml content from the snippet below:

The time has come. Now you know everything that has to be done before writing TestNG & Selenium Test Case. Without further ado — let’s do it!

1 — Open the FirstTest class

2 — Add the firstMethod() to the class with the @Test() annotation, like shown below

3 — Annotation should be highlighted in red, so please do right-click on it and select Show Context Actions > Import class

4 — Add three comments into the method, as shown below. This would be a good indication of what we’re trying to achieve here. Also, this is a kind of Test Driven Development (TDD) approach, as first of all, we need to figure out what to implement and then proceed with the actual coding.

5 — For the sake of simplicity of the first Test Case, we’re going to use the Java example from the official Selenium Documentation (https://www.selenium.dev/documentation/) and translate it into our code.

Lines 1–14: Imports every package that is required to run the Test Case

Line 20: We’re using the WebDriverManager (https://bonigarcia.dev/webdrivermanager/) to skip the configuration of the ChromeDriver (but still, please be aware of that — you have to install the Google Chrome browser on your machine to run automated tests)

Lines 21–22: We’re setting up variables driver and wait to use them in the test

Line 24: We’re using the driver.get() method to open the “https://bing.com” page

Line 25: We’re using the driver.findElement() method to retrieve WebElement from the page called by driver. We’re also using the chained methods By.name().sendKeys(), which finds an element by its name (which is “q”), types “cheese” into the search field, and imitates hitting the Return/Enter key.

Line 27: We’re waiting until the h3 tag is visible in the DOM (https://en.wikipedia.org/wiki/Document_Object_Model) and retrieving it as a WebElement variable called firstResult

Line 28: We’re using the default Java console log to print out the text of the h3 element

Line 29: We’re closing WebDriver, as it’s no longer needed

Disclaimer: I am aware that there is no actual assertion in the end, but I wanted to keep this example as simple as possible for the time being. Eventually, we’re going to cover assertions as well.

Phew, that was a lot. To sum up — in this episode we’ve covered:

  • Creating new Maven project within IntelliJ IDEA
  • How to use pom.xml and what’s its purpose
  • How to write useful README files
  • How to configure basic TestNG setup with testng.xml
  • How to search for dependencies using Global Maven Repository and add them to pom.xml
  • How to write our first Selenium Test Case

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/Awakening


All illustrations made by Tomasz Buga

Cat GIF source — https://tenor.com/view/give-food-cat-adorable-kitty-please-gif-17986583



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.