...
Code Block | ||
---|---|---|
| ||
<plugin> <groupId>info.novatec.testit.livingdoc</groupId> <artifactId>livingdoc-maven-plugin</artifactId> <version>1.0.0</version> ... <!-- further configuration here --> </plugin> |
For automatic downloads and upgrades, it is possible to add additional repositories to your project's pom.xml like this:
Code Block | ||
---|---|---|
| ||
<repositories>
<repository>
<id>novatec</id>
<url>http://nexus.novatec-gmbh.lan/content/groups/public</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
</repositories>
<pluginRepositories>
<id>novatec</id>
<url>http://nexus.novatec-gmbh.lan/content/groups/public</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepositories> |
Configuring the LivingDoc Maven Plugin
Within the default Maven Build Lifecycle, there are three phases using the Maven Plugin.
- During the Pre-Integration Test, the plugin is used to compile and copy the fixture classes of an application. By default, the compiled classes are copied to:
${project.build.directory}/fixture-test-classes/
- During the next phase, the Integration Test, the plugin is used to execute the specifications of an application. As the result of an execution, it generates reports in plain HTML or XML file format which are by default stored in:
${basedir}/target/livingdoc-reports/
- Finally, during the Post-Integration Test, the plugin creates the fixture jars of an application. These are typically generated in:
${basedir}/target/
In step one ("Installing the Maven Plugin") we had a look on a short block of code where it said "further configuration here". Below you find an example of how said configuration could look like.
...
language | xml |
---|
...
Configuring the LivingDoc Maven Plugin
Within the default Maven Build Lifecycle, there are three phases using the Maven Plugin.
- During the Pre-Integration Test, the plugin is used to compile and copy the fixture classes of an application. By default, the compiled classes are copied to:
${project.build.directory}/fixture-test-classes/
- During the next phase, the Integration Test, the plugin is used to execute the specifications of an application. As the result of an execution, it generates reports in plain HTML or XML file format which are by default stored in:
${basedir}/target/livingdoc-reports/
- Finally, during the Post-Integration Test, the plugin creates the fixture jars of an application. These are typically generated in:
${basedir}/target/
In step one ("Installing the Maven Plugin") we had a look on a short block of code where it said "further configuration here". Below you find an example of how said configuration could look like.
Code Block | ||
---|---|---|
| ||
<plugin> <groupId>info.novatec.testit.livingdoc</groupId> <artifactId>livingdoc-maven-plugin</artifactId> <version><!-- your version of the LivingDoc Maven Plugin --></version> <configuration> <source><!-- your source version --></source> <target><!-- your target version --></target> <fixtureSourceDirectory><!-- source directory of your fixtures, for example: src/fixture/java --></fixtureSourceDirectory> <fixtureOutputDirectory><!-- output directory of the compiled fixture classes, for example: target/fixture-test-classes --></fixtureOutputDirectory> <specsDirectory><!-- destination for downloaded specification files, for example: src/sprecs--></specsDirectory> <reportsDirectory><!-- destination for generated HTML reports, for example: target/livingdoc-reports</reportsDirectory> <reportsType><!-- the file format of your reports (XML or HTML, default is HTML) --></reportsType> <resources> <resource> <directory><! -- directory for a specific resource. Example: src/fixture/resources--></directory> <excludes> <exclude>**/*.java</exclude> </excludes> </resource> </resources> <repositories> <repository> <resource> <directory><! -- directory for a specific resource<type><!-- fully qualified name of your suit resolver class, for instance: info.novatec.testit.livingdoc.repository.FileSystemRepository --></type> <root><!-- root directory of the current repository. Example: ${basedir}/src/fixture/resourcesspecs --></directory>root> <suites> <excludes> <suite><!-- the suit's <exclude>**/*.java</exclude> URI --></suite> </excludes>suites> </resource>repository> </resources> <repository> <repositories> <repository> <type><!-- fully qualified name of your suittest resolver class, for instance: info.novatec.testit.livingdoc.repository.FileSystemRepository --></type> <root><!-- root directory of the current repository. Example: ${basedir}/src/fixture/specs --></root> <tests> <suites> <suite><<test><!-- the suittest's URI --></suite>test> </suites>tests> </repository> </repositories> <goalPrefix><!-- the prefix <repository>that will be associated with the plugin (optional, see below "Using the LivingDoc <type><!-- fully qualified name of your test resolver.Maven Plugin"), eg: livingdoc --></type>goalPrefix> <tests> <test><!-- the test's URI --></test> </tests> </repository> </repositories> <goalPrefix><!-- the prefix that will be associated with the plugin (optional, see below "Using the LivingDoc Maven Plugin"), eg: livingdoc --></goalPrefix> </configuration> </plugin> |
Using the LivingDoc Maven Plugin
Executing specification fixtures
...
</configuration>
</plugin> |
Using the LivingDoc Maven Plugin
Executing specification fixtures
Generally, the goals of the Maven Plugin correspond to the phases of the default Maven Build Lifecycle (with exception of the Freeze goal). Therefore, in order to interact with our fixture sources, we only have to tell Maven until which goal it should run.
NOTE: In order to use a prefix as we do below, it might be necessary to define the goal Prefix tag within the plugin configuration (see the code box above).
...
Now that we know which goals exist for the
Maven Plugin, let's have a closer look at each of them.livingdoc:compile compile
Compiles the fixtures of an application.
...
fixtureSourceDirectory: Source directory containing the fixture classes to be compiled
- Type: java.io.File
Expression (example): src/fixture/java
fixtureOutputDirectory: Output directory in which the compiled sources are placed.
- Type: java.io.File
- Expression: ${project.build.directory}/fixture-test-classes
livingdoc:resources resources
Copies resources for the main source code to the main output directory.
...
resources: List of resources to be copied to the output directory.
- Type: java.util.List
- Expression: none
fixtureOutputDirectory: Output directory the resources are copied to.
- Type: java.io.File
- Expression: ${project.build.directory}/fixture-test-classes
livingdoc:run run
Executes specifications.
Mojo attributes:
...
basedir: Base directory of the project under test.
- Type: java.io.File
- Expression: ${basedir}
classesDirectory: Contains the generated classes of the project under test.
- Type: java.io.File
Expression: ${project.build.outputDirectory}
- fixtureOutputDirectory: Contains generated fixture classes of the project under test.
- Type: java.io.File
- Expression: ${project.build.directory}/fixture-test-classes
- reportsDirectory: Output directory for generated reports.
- Type: java.io.File
- Expression: ${project.build.directory}/livingdoc-reports
livingdoc:fixture-jar
Builds the fixture jars.
Mojo attributes:
...
fixtureOutputDirectory: Directory containing the compiled fixture classes.
- Type: java.io.File
- Expression: ${project.build.directory}/fixture-test-classes
livingdoc:freeze
Downloads specification files from a remote repository and stores them locally.
...
Code Block | ||
---|---|---|
| ||
<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/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <artifactId>livingdoc-core</artifactId> <packaging>jar</packaging> <name>${project.subproject.title}</name> <parent> <groupId>info.novatec.testit.livingdoc</groupId> <artifactId>livingdoc</artifactId> <version>3<version>1.10.2<1</version> </parent> <build> <resources> <resource> <directory>src/main/filter</directory> <filtering>true</filtering> <targetPath>../filtered-sources</targetPath> <includes> <include>**/*.java</include> </includes> </resource> <resource> <directory>src/main/resources</directory> <filtering>false</filtering> </resource> </resources> <plugins> <plugin> <groupId>info.novatec.testit.livingdoc</groupId> <artifactId>livingdoc-maven-plugin</artifactId> <version>${livingdoc.maven.plugin.version}</version> <configuration> <source>1.7</source> <target>1.7</target> <fixtureSourceDirectory>src/fixture/java</fixtureSourceDirectory> <fixtureOutputDirectory>target/fixture-test-classes</fixtureOutputDirectory> <specsDirectory>src/specs</specsDirectory> <reportsDirectory>target/livingdoc-reports</reportsDirectory> <reportsType>xml</reportsType> <systemUnderDevelopment>info.novatec.testit.livingdoc.systemunderdevelopment.LivingDocSystemUnderDevelopment</systemUnderDevelopment> <resources> <resource> <directory>src/fixture/resources</directory> </resource> </resources> <repositories> <repository> <name>Seeds</name> <type>info.novatec.testit.livingdoc.repository.FileSystemRepository</type> <root>${basedir}/src/fixture/specs</root> <suites> <suite>Seeds</suite> </suites> </repository> </repositories> <goalPrefix>livingdoc</goalPrefix> </configuration> <executions> <execution> <id>livingdoc</id> <goals> <goal>compile</goal> <goal>resources</goal> <goal>fixture-jar</goal> <goal>run</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project> |
...
Code Block | ||
---|---|---|
| ||
<repositories> <repository> <name>Demo</name> <type>info.novatec.testit.livingdoc.repository.FileSystemRepository</type> <root>${basedir}/src/fixture/specs</root> <suites> <suite>Demo</suite> </suites> </repository> <repository> <name>DemoPhoneBook</name> <type>info.novatec.testit.livingdoc.repository.FileSystemRepository</type> <root>${basedir}/src/fixture/specs</root> <suites> <suite>DemoPhoneBook</suite> </suites> </repository> </repositories> |
Command line options
Skip execution of the LivingDoc tests
Code Block -Dmaven.livingdoc.test.skip=true
Change the report type (default is HTML)
Code Block -Dmaven.livingdoc.reports.type=xml
Stop execution on first failed test
Code Block -Dmaven.livingdoc.test.stop=true
Activate debug mode
Code Block -Dmaven.livingdoc.debug=true
Ignore failed tests during execution (won't cause Maven to stop execution with an error message)
Code Block -Dmaven.livingdoc.test.failure.ignore=true
Sonar (legacy)
Sonar, also known as SonarQube, is an open platform that aims at managing the quality of your code. The Sonar LivingDoc Plugin feeds Sonar with the test reports provided by the LivingDoc Maven Plugin.
The easiest way to produce a Sonar report using LivingDoc test reports is the following:
Code Block |
---|
mvn clean integration-test sonar:sonar |
The integration-test will trigger the following goals:
Please note that in order to use the Sonar LivingDoc Plugin, the LivingDoc reports need to have XML file format which can be achieved by doing either of the following:
...
Add the reportsType tag to the plugin configuration in your project's pom.xml
Code Block |
---|
<reportsType>xml</reportsType> |
...
Command line options
Skip execution of the LivingDoc tests
Code Block -Dmaven.livingdoc.test.skip=true
Change the report type (default is HTML)
Code Block -Dmaven.livingdoc.reports.type=xml
Stop execution on first failed test
Code Block -Dmaven.livingdoc.test.stop=true
Activate debug mode
Code Block -Dmaven.livingdoc.debug=true
Ignore failed tests during execution (won't cause Maven to stop execution with an error message)
Code Block -Dmaven.livingdoc.test.reportsfailure.type=xmlignore=true