Maven For Selenium. Are you new to Automation testing…
By: Amar Tanwar
Tags: Java, Maven, Selenium

Are you new to Automation testing? Hearing about Maven to build your automation suite but don't know how to use it and how it can help in running automation test.

So here is a solution to that. Here will go through how we can leverage Maven features in our Test Automation Framework.

Why should we create the Maven Project?

To manage all dependencies.

Helps to integrate test to the pipeline.

To generate and publish artifacts.

Helps to generate a test report after every test run.

Before start Creating Maven project let’s understand what is maven and features of it. which will be using in our Test Automation Framework.

What is Maven?

Maven is a build management tool which does all the job of a programmer to run code using a single command. It generates source code, compiling code, packaging code to a jar, running tests, generating reports etc. This is how it makes a programmer’s life is easy to handle huge projects.

How do I install Maven?

Please follow the below link to install Maven in mac and Windows.

Note: I have used IDE as IntelliJ and mac system while writing this blog.

How do I make my first Maven project?

To create our first Maven project we are going to use Maven’s archetype mechanism. In Maven, an archetype is a template of a project which is combined with some user input to produce a working Maven project that has been tailored to the user’s requirements.

In order to create the simplest of Maven projects, execute the following from the command line:

mvn -B archetype:generate \

-DarchetypeGroupId=org.apache.maven.archetypes \

-DgroupId=com.mycompany.app \

-DartifactId=maven-for-testers

Let’s understand the above command.

-DarchetypeArtifactId=maven-archetype-archetype is the archetype that maven has provided to create a new custom archetype.

is the archetype that maven has provided to create a new custom archetype. -DgroupId=com.howtodoinjava.archetype is the group id of the archetype we will now create.

is the group id of the archetype we will now create. -DartifactId=maven-howtodoinjava-archetype is the artifactId of the archetype we will now create.

is the artifactId of the archetype we will now create. -Dversion=1.0-SNAPSHOT is the version of the maven archetype.

Once you have executed this command, you will notice a few things have happened. First, you will notice that a directory named my-app has been created for the new project, and this directory contains a file named pom.xml that should look like this:

Heart(pom.xml) of Maven?

pom.xml contains the Project Object Model (POM) for this project. The POM is the basic unit of work in Maven. The POM contains every important piece of information about your project.

Let’s walk you through from each tag of the pom.xml.

project - This is the top-level element in all Maven pom.xml files.

- This is the top-level element in all Maven pom.xml files. modelVersion - This element indicates what version of the object model this POM is using.

- This element indicates what version of the object model this POM is using. groupId - This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plugins.

- This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plugins. artifactId - This element indicates the unique base name of the primary artifact being generated by this project usually we keep artifactId name is a project name. The primary artifact for a project is typically a JAR file.

- This element indicates the unique base name of the primary artifact being generated by this project usually we keep artifactId name is a project name. The primary artifact for a project is typically a JAR file. packaging - This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). The default value for the packaging element is JAR so you do not have to specify this for most projects.

- This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). The default value for the packaging element is JAR so you do not have to specify this for most projects. version - This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development. We will discuss the use of snapshots and how they work further on in this guide.

- This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development. We will discuss the use of snapshots and how they work further on in this guide. name - This element indicates the display name used for the project. This is often used in Maven’s generated documentation.

- This element indicates the display name used for the project. This is often used in Maven’s generated documentation. url - This element indicates where the project’s site can be found. This is often used in Maven’s generated documentation.

- This element indicates where the project’s site can be found. This is often used in Maven’s generated documentation. description - This element provides a basic description of your project. This is often used in Maven’s generated documentation.

- This element provides a basic description of your project. This is often used in Maven’s generated documentation. dependencies- The dependencies section of the pom.xml lists all of the external dependencies that our project needs in order to build (whether it needs that dependency at compile time, test time, run time, or whatever).

After the archetype generation of your first project you will also notice that the following directory structure has been created:

Here if you notice there are two parent folder created under source.

main- Contains all source file. We should always keep all the classes other than test class under src/main folder.

Contains all source file. We should always keep all the classes other than test class under folder. test- Contains all the test source file. We should always keep all the test classes under src/test folder.

Now let's talk about different maven commands to build the project.

How do I compile my application sources?

mvn compile

The first time you execute this (or any other) command, Maven will need to download all the plugins and related dependencies it needs to fulfill the command. From a clean installation of Maven, this can take quite a while (in the output above, it took almost 4 minutes). If you execute the command again, Maven will now have what it needs, so it won’t need to download anything new and will be able to execute the command much more quickly. All the compiled classes will be placed in ${basedir}/target/classes.

How do I compile my test sources and run my unit tests?

mvn test

Before compiling and executing the tests Maven compiles the main code (all these classes are up to date because we haven’t changed anything since we compiled last).

How do I only compile my test resources but not execute the tests?

mvn test-compile

How do I create a jar?

mvn package

It compiles the project and runs all test and at last, it generates jar into the target folder. If you take a look at the POM for your project you will notice the packaging element is set to jar. This is how Maven knows to produce a JAR file from the above command. You can now take a look in the ${basedir}/target directory and you will see the generated JAR file

How to install a jar into the local maven repository?

mvn install

here Local repository is ~${user.home}/.m2/repository. Now this installed jar can be consumed by any other projects.

How to clean the target folder for a fresh start?

mvn clean

How do I use external dependencies?

The dependencies section of the pom.xml lists all of the external dependencies that our project needs in order to build (whether it needs that dependency at compile time, test time, run time, or whatever). Below snapshot shows the external dependency of TestNG in the maven repository.

Mentioning external dependency in pom.xml.

For each external dependency, you’ll need to define at least 4 things: groupId, artifactId, version, and scope. The groupId, artifactId, and version are the same as those given in the pom.xml for the project that built that dependency. The scope element indicates how your project uses that dependency and can be valued like compile, test, and runtime. Will discuss later more about scope.

Now we have learned enough about how to compile the project, generate jars, executing test etc. Lets now understand how to run tests by applying filters or using testng.xml.

How do I run tests in Maven from testng.xml?

To run tests in maven from testng.xml will be using Maven Surefire Plugin. For that, we need to add below plugin in POM.xml

If you have noticed that we are passing testng.xml under tag suiteXmlFile. Which is nothing but testng file which we want to run?

Now if we run the maven command to run tests.

mvn test

It will target only the tests which are mentioned in the testng.xml file.

Problem: In POM.xml if we hard code TestNG file name then every time maven will execute the same file. What if the user wants to run different TestNG files for different scenarios.

Solution: We can pass the TestNG file name as a system property and value for that property we can mention in maven command. So whatever the file name you pass in command, Maven will execute tests from that file only.

mvn test -DtestFile=regressionTest.xml

or

mvn test -DtestFile=smokeTest.xml

How do I run tests in Maven using TestNG GroupBy function:

As above we learned how we can run tests from a testng.xml file. What if we don't want to run tests from a testng.xml file instead we want to run tests based on specific groups defined in the test class.

Solution: We can pass the group name as a system property and value for that property we can mention in maven command. So whatever the group name will be passed in command, Maven will execute tests from that group only. Under exclude groups, we can mention the groups which we don’t want to run or should be excluded from the test.

mvn test -DgroupName=SMOKE

or

mvn test -DgroupName=REGRESSION,SMOKE

Under exclude groups, we have hardcoded value as “SMOKE”. Which can also be passed as system properties. So run time testng will decide which groups have to be excluded from execution.

mvn test -DgroupName=REGRESSION,SMOKE -DexGroupName=FUNC

Running Tests in Parallel using Maven:

with the above configuration, we can run methods in parallel in 3 threads. We can also run 2 suites in parallel.

Now we have understood how to use maven to run tests. Let’s now go through some basic question from Maven.

Maven Build Lifecycle:

validate — validate the project is correct and all necessary information is available

— validate the project is correct and all necessary information is available compile — compile the source code of the project

— compile the source code of the project test — test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed

— test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed package — take the compiled code and package it in its distributable format, such as a JAR.

— take the compiled code and package it in its distributable format, such as a JAR. verify — run any checks on results of integration tests to ensure quality criteria are met.

are met. install — install the package into the local repository, for use as a dependency in other projects locally.

— install the package into the local repository, for use as a dependency in other projects locally. deploy — done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.

Maven Repositories:

In Maven terminology, a repository is a directory where all the project jars, library jar, plugins or any other project specific artifacts are stored and can be used by Maven easily.

Maven repository is of three types. The following illustration will give an idea regarding these three types.

local

central

remote

Local Repository-

Maven local repository is a folder location on your machine. It gets created when you run any maven command for the first time. Maven local repository keeps your project’s all dependencies (library jars, plugin jars etc.). When you run a Maven build, then Maven automatically downloads all the dependency jars into the local repository. It helps to avoid references to dependencies stored on the remote machine every time a project is build. Below snapshot shows how we can give dependency of the jar from a local repository. This is useful when you are working on multiple projects and want to use the jar of one project into another project without publishing artifacts.

Central Repository-

Maven central repository is a repository provided by the Maven community. It contains a large number of commonly used libraries. When Maven does not find any dependency in a local repository, it starts searching in a central repository.

Below is a snapshot of the maven central repository.

Remote Repository-

Remote repositories are private repositories. Everyone won't have access to these repositories as we have for maven central repository. Companies usually have a remote repository to keep all jars private. To give dependency of a jar from remote repository we need to mention the repository path like given below.

Closing Notes

There are still many more things which we can do it using Maven but for now, let's get our hand dirty with only basics of Maven. And most important don’t be stuck with basics of Maven, try to push your self to advance Maven so you can leverage most of the features of Maven in your Automation Framework.

Source: https://maven.apache.org/surefire/maven-surefire-plugin/examples/testng.html