{{announcement.body}}
{{announcement.title}}

Maven Plugin Testing - In a Modern way - Part II

DZone 's Guide to

Maven Plugin Testing - In a Modern way - Part II

In part two of this series, we take a deeper look into other aspects of testing Maven plugins (e.g. how we check the logging output of a Maven build process).

· Java Zone ·
Free Resource

In the first part of the series - Maven Plugin Testing - In a Modern way - Part I we have seen how to make the basic setup with The Integration Testing Framework and run very basic integration test. 

In this second part we will take a deeper look into other aspects of testing Maven plugins in particular how we check the logging output of a Maven build process. Let us begin with writing more than a single integration test case. You can of course write multiple test cases within a single test class like the following:

Java


Apart from the test cases them self we need the according projects which are used as test projects which looks like this:

Plain Text
 


So after we have executed the integration tests (mvn verify) the resulting directory structure will look like this:

Plain Text
 


Based on the resulting directory structure you can see each test case completely separated from each other. This means also that each test case contains it's own maven cache (.m2/repository). You can find also the separated log file outputs and the separate project directory which contains the test project after the test run. That is very helpful for later issue analysis. 

So now let us take a deeper look into the test cases:

Java


In each test, you have seen a parameter to the test method MavenExecutionResult result. The injected parameter gives you access to the result of the test build of project. This class contains appropriate methods to access the result of the build process, the project cache, the project itself (in other words to the directory) and of course to the different logging output files which have been created during the run of the test. 

So the first thing you usually check would be if the built has been successful or not. This depends on the type of integration test you are writing. This can be achieved by using the following:

Java


This expects the built being successful as you already suspected. You can of course write a test which assumes that your built must fail which can be expressed like this:

Java


So the isSuccessful() means the return code 0 whereas isFailure() represents a return code which is not 0.

You can combine the check for a successful build and no warning output like this:

Java


So .out() will access the created output file of the build mvn-stdout.log. The .warn() will filter out all lines which start with [WARNING] . The .isEmpty() is part of AssertJ framework for assertion against lists which implies that the result is empty.

So now let us check some output which is produced by a usual build. The output emits [INFO]  so the test can use .out().info(). instead which looks like this:

Java


The .containsSubsequence(..) checks that the sequence is in the correct order with optional supplemental parts in between.  While writing plugins/extensions it sometimes happens that you emit an information on WARN Level to give some hints what needs to be mentioned but will not fail a build.

The maven-jar-plugin for example will emit a warning if no content will be added into the jar. This could be checked like the following:

Java


So this can be combined to create a more comprehensive test case like this:

Java


If you write a plugin which contains a parameter for encoding an output like this (might look familiar to you) should be produced:

Plain Text


This can be checked within a test case like this:

Java
 




xxxxxxxxxx
1


1
assertThat(result)
2
  .out()
3
  .warn()
4
  .containsExactly("Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!");



So this it is for Part II. If you like to learn more about the Integration Testing Framework you can consult the users guide. If you like to know the state of the release you can take a look into the release notes.

If you have ideas, suggestions or found bugs please file in an issue on github.

An example can be found on GitHub.

Topics:
integration-testing, java, maven 3.0

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}