You may have many projects or teams that use Quantum and want 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. In this article, the "library" project is referred to as the Parent and the actual "test code" project as the Child.
To configure separate projects, you need to add the appropriate references to the pom.xml file. 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 a reference to the pom.xml information supplied in the Parent. In this case, the Parent's name is listed as follows.
<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 the project is divided, 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 version Maven using this method.
The Child project will look like 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 perform a Maven install on the project, or from the command line mvn install.
If running from CI, 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 need 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: