Q7 Maven plugin works with Maven 3 and provides an ability to launch Q7 automated tests during maven build.
For ease of use and ability of further customization, Q7 tests projects use custom packaging type q7test, since it is a natural way to associate a particular lifecycle with a project. The table below describes all phases used by Q7 Maven plugin and actions performed on these phases.
Packages Q7 project and execution results as artifacts (see below)
Basic plugin configuration
Below is a basic POM template which can be used as starting point of automating Q7 tests with Q7 Maven plugin. Put it into your Q7 project and configure as described below
Important things to note here:
- Packaging type is set to q7test
- Xored Maven repository added to pluginsRepositories
The configuration element can have following main child elements described below: aut, q7 ,testOptions and skipTags.
Q7 Maven Plugin supports two sources of applications-under-tests – it can either use Maven artifact resolution to download AUT from Maven repository, or get it explicitly from file system or http server. The configuration of AUT is specified in plugin configuration section under
aut element. If we use Maven artifact resolution, then we assume that AUT is compiled using tycho, therefore we can automatically define classifier (which consists of OS, Window System and architecture, for example win32.win32.x86 or macosx.cocoa.x86_64) for current machine and hence AUT can be defined like this
In this case our plugin determines the classifier of the current platform (and we assume that classifier is constructed from os.ws.arch), assumes that packaging type is zip, and resolves the artifact using Aether, by taking the latest version. However, version, classifier and extension can be explicitly specified:
In case when application-under-test is not being deployed into Nexus, it is possible to specify application-under-test location by setting explicit property which can contain either path to AUT location on local file system, or http url to download AUT from. If path is not absolute, then it is resolved relative to project base dir. If
explicit parameter is provided, other parameters are ignored:
Explicit AUT specification supports some initial substitution – for example tag [platform] can be used to substitute the eclipse classifier of current platform (i.e. linux.gtk.x86_64) Example:
The explicit location specification when executed on win32 will be resolved to
Sometimes it might be useful to make some certain features available in testing assembly, but not included into the final product. For this purpose, it is possible to specify injection parameters for AUT to specify which features from which update sites should be installed into AUT before testing. Here's the example configuration
Extra command-line arguments for application and/or for Java VM can be specified like this:
In case of using linked projects or folders in Workspace context, it might be required to specify an extra projects to be imported into Q7 Runner workspace. This can be done by using
Options related to test execution are specified under testOptions element in plugin configuration. There are no required options here, so by default this element is just omitted.
The example below sets timeout options for the whole test suite and for a single test:
The complete list of parameters with their defaults is provided on Q7 Runner page (section Runtime Options).
Tags to skip
Sometimes it might be valuable to skip certain test cases during test execution, for example if tests depend on specific operating system or other environment. For this purpose it is possible to mark such tests in Q7 IDE with some specific tag and then specify
<skipTags> option, for example:
Q7 supports custom user reports, see more information here – http://github.com/xored/q7.extensions.reporting. In order to use custom reporter during maven build, use <report> node with two child properties – id to identify the reporter, and name to specify a custom name like this:
Sometimes it might be useful to see how much memory is used by AUT after completion of each test. You can turn on outputting that information by using
By default Q7 attempts to find a license file in user's home directory. Use
q7/licenseFile element to override the default license file location:
Q7 Launcher resolution
By default, Q7 Maven plugin just resolve artifact with groupId = com.xored.q7 and artifactId = q7runner and takes the latest version it can find. However, in some rare cases it might be necessary to override this information. It is possibly by specifying q7 element under plugin configuration. The contents of this element are the same as for specifying AUT.
package phase of Q7 lifecycle produces two artifacts:
- The project itself as primary artifact (so it can be references by other projects)
- Q7 execution results/logs/outputs and other information which can be helpful to identify the reason of failures. This artifact has classifier
Below is the complete list of items included into
- q7 – Base directory for q7-runner files
- report.xml – Q7 report
- stdout.txt – Q7 process output stream contents
- stderr.txt – Q7 process error stream contents
- log.txt, log1.txt – Q7 workspace logs (.log and .bak_N.log files from .metadata)
- For each AUT (specified by
testOptionsthe separate folder
aut<N>is created inside results artifact archive with the following contents:
- log<N>[restart<M>].txt – AUT workspace logs (including logs from restarts).
- out.txt – Combined out/err stream contents
- launch – For each launch configuration with name
Foo, the following dirs are created
- launch.xml - Launch configuration arguments
- ... - directories from
This is a trivial example which uses most of defaults provided by q7-maven-plugin.
Dependencies between test projects are described in the same way as it is for other maven projects, one thing to note is that type element must be set to q7test:
Current implementation assumes that all dependencies are packed and located either in local or in some of configured remote repositories which means that when using dependencies between projects it is necessary to use at least install phase.