CI Dashboard with Quantum
Learn how to utilize the CI Dashboard for local executions using the Quantum framework as an example. This process can be easily applied to other Maven-based frameworks.
The CI Dashboard, which is a specific view of Perfecto's Smart Reporting feature, can be a very useful tool to spot trends in executions. Usually, it is meant for test executions triggered by the Continuous Integration server, like Jenkins, TeamCity, Bamboo, and so on. In some cases, you might find it helpful when running a test suite locally, leveraging the CI Dashboard to instantly see trends and compare runs.
Even when running the tests locally, you can send a CI Job Name as well as a "job number" to the reporting server as testing context, allowing you to view executions as if triggered from CI. This can be useful when trying to re-run a CI job locally or when working on or stabilizing a new test suite that is not yet part of the production CI flow.
Send options
We usually want to pass one Job Name (above DailyBuild) with incrementing build numbers. Each bar on the right groups all tests of a specific build number. The following options are available:

When executing a Maven project, we can pass parameters to Maven. We know from CI Integration articles that Quantum expects the parameters reportium-job-name
and reportium-job-number
(see also CI Jenkins with Quantum). Therefore, when running the project as a Maven project, we can pass these parameters manually, for example by manually incrementing the build number by 1. For example, you can use the command line to run the following command:
mvn clean test -Dreportium-job-name=myJobName -Dreportium-job-number=42
Using Eclipse as IDE, we can do the same by creating a Run Configuration, where we can then simply pass different values per execution, as follows:

You can add an auto-incrementing build number that increases the build automatically every time the suite is triggered, for example by simply using the epoch time.
With Quantum, if we want to modify as little as possible (not creating new test listeners), we can use the pom.xml
properties.
The following example by default sends the time stamp formatted a certain way as Job number (if no other parameter has been supplied executing the Maven project as in 1.)
We are using the maven build timestamp. In the first snippet, we set the way we want it formatted, as general properties right at the beginning of the pom.xml
:
Define format of the build number
<properties>
<maven.build.timestamp.format>yyMMddHHmm</maven.build.timestamp.format>
...
</properties>
Then we define the default system variables within the Surefire plugin paragraph:
Set SystemProperties in Surefire plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<configuration>
<argLine>-Dfile.encoding=${project.build.sourceEncoding}</argLine>
<systemPropertyVariables>
<reportium-job-name>phil_testCI</reportium-job-name>
<reportium-job-number>${maven.build.timestamp}</reportium-job-number>
<application.properties.file>resources/application.properties</application.properties.file>
</systemPropertyVariables>
...
</plugin>

By setting the default values as in option 2, each test execution should be displayed under the default build name, with the current timestamp as the build number. If we now want to execute it as part of a different CI job name, we just need to set pass the -Dreportium-Job-Name
parameter, and the build number will be supplied.
Also in this section
See also
See also the Perfecto Knowledgebase.