You may have many projects or teams that use Quantum and wish to separate the Core (maven dependencies, utilities classes, and so on), which should be shared by many projects and teams, from the actual test code (locators, pages, scenarios, tests, configurations, as so on). Keeping the core and the test code separate helps create a global library that is easier to maintain. It also helps manage Maven dependency versions when upgrades occur to the Quantum Project. This library can then be inherited by any other projects down the line. This article refers to the "library" project as the Parent and the actual "test code" project as the Child.
Configuring the separate projects is quite simple. It mainly means chopping up the pom.xml file with the appropriate references. For the Parent, the file will contain all properties, dependencies, and repository items from the pom.xml found at Project Quantum, as shown in the following code snippet.
<?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>com.qmetry</groupId>
<artifactId>quantum-parent</artifactId>
<version>2.2</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
.....
</properties>
<repositories>
<repository>
<id>qaf</id>
<url>https://qmetry.github.io/qaf/dist</url>
</repository>
<repository>
<releases>
<updatePolicy>always</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<id>ps</id>
<url>https://github.com/Project-Quantum/mvn/raw/master/repository</url>
</repository>
.......
</repositories>
<dependencies>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>1.3</version>
</dependency>
....
</dependencies>
</project>For the Child project, the file will contain a subset of properties, all build items, and finally a reference to the pom.xml information we supplied in the Parent. In this case, the Parent's name is listed as:
<groupId>com.qmetry</groupId>
<artifactId>quantum-parent</artifactId>
<version>2.2</version>The child project would look like the following example.
<?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>com.qmetry</groupId>
<artifactId>quantum-child</artifactId>
<version>2.0-SNAPSHOT</version>
<properties>
<testngXmlDir>src/main/resources/config</testngXmlDir>
<testngXmlFile>testng_appium.xml</testngXmlFile>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<encoding>${project.build.sourceEncoding}</encoding>
</configuration>
</plugin>
.........
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.qmetry</groupId>
<artifactId>quantum-parent</artifactId>
<version>2.2</version>
</dependency>
</dependencies>
</project>Now that we have divided up the project, the structure of the Parent project is really dependent on your needs. You could have many utility or reusable classes, or you may not have any if you just wish to easily version Maven using this method.
The Child project will look just like any other standard Quantum Framework.
To utilize the Parent project in the Child, you must compile and install the project into your local Maven repository. To do this, you simply perform a Maven install on the project, or from the command line mvn install.
If running from CI, you would want to run the Parent first and then the child, in a cascading fashion, so that you perform a fresh install of the Parent before the Child is executed. This ensures that any changes are picked up at runtime.
Lastly, you may opt to update the Parent artifact version between updates. In this case, you would then be required to update every child project with the new version number to pick up the changes. This may be desired in many cases. However, for easier management, you could also leave the version number the same between updates if the updates are small and non-consequential to test cases that may already be written in the Child projects.
For an example of each project, see:
