Maven Plugin Testing - In a Modern way - Part III
Maven Plugin Testing - In a Modern way - Part III
In this third part of this series, we dive into how Maven will be called by default during the integration tests and how we can influence that behavior.
Join the DZone community and get the full member experience.Join For Free
In the second part of the series - Maven Plugin Testing - In a Modern way - Part II we have seen how to make the basic integration test while checking the log output of Maven builds.
In this third part we will dive into how Maven will be called by default during the integration tests and how we can influence that behavior.
Let us begin with the following basic integration test (we ignore the project which is used for testing at the moment.)
The above test will execute Apache Maven by using the following options by default:
That means that each execution within the Integration Testing Framework will be done like this:
To get that correctly working and in particular having a local cache for each integration test case, the integration testing framework will add:
-Dmaven.repo.local=... to each call as well. This is necessary to get the following result:
-Dmaven.repo.local=... can't be changed at the moment. The used command line arguments are wrote into the mvn-arguments.log file which can be consulted for later analysis. So in the end a command line for an integration test looks like this:
The goal which is used (package) and how it can be changed will be handled in Part IV of the series. So far so good, but sometimes or maybe more often it is needed to add other command line options to a Maven call in particular in relationship with integration tests.
Sometimes your own plugin/extension will printout some useful information on debug level but how to test that? We have mentioned before that the options which are used for an integration test does not contain the debug option. We can now express the need via this (basic_configuration_with_debug):
It's important to say that by using the @MavenOption(..) automatically all other previously mentioned command line options will not being used anymore. In this example the final command line looks like this for the test case basic_configuration_with_debug:
mvn -Dmaven.repo.local=<path> --debug package
So based on turning on debugging output it means that you can check debugging output like this:
If you like to have the
--show-version as well as the
--error option back in your test case have to add them like this:
The result will be that your Maven command line now looks like before including the supplemental
That shows that you can easily combine several command line options for a test case via the
Some command line options in Maven need supplemental information like
--log-file <arg> which requires the name of the log file to redirect all the output into. How can we express this with the
@MavenOption annotation? This can simply being achieved like the following:
As you can see in the above example you have to give the option via the value of the annotation. The parameter of the option has to be given via parameter. In this case we have used static imports to make it more readable. You can of course work without static imports like this (Just a matter of taste):
So what about using the same command line options for several test cases? You can simply add the command line options onto the test class level which looks like this:
This means that for each given test case (case_one, case_two, case_three and case_four) the same set of command line options will be used. Apart from that it is much more convenient to define the command line options only once and not for every single test case.
Wait a second. I want to execute case_four with different command line options? Ok no problem just define the set command line options onto that particular test case like in the following example:
The test case case_four will not inherit the command line options defined on the class level. It will use only those defined on the test case itself.
Now a usual developer question: I'm really lazy I don't want to write all those four MavenOption annotation for each test class. In particular if I need to change those command line options I have to go through each test class one by one?
There is of course a more convenient solution for that problem. This is called a meta annotation. We can simply create a meta annotation which we call MavenTestOptions. This meta annotation looks like this:
This meta annotation can now being used to change the test class of the previous example like this:
The above can be improved a bit more. We can integrate the annotation
@MavenJupiterExtension into our self defined meta annotation like this (In the example project I have named the meta annotation
@MavenITExecution to have different examples in one project.):
Based on that we can change the test case to look like this:
So this it is for Part III. 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 of the shown uses cases can be found on GitHub.
Published at DZone with permission of Karl Heinz Marbaise . See the original article here.
Opinions expressed by DZone contributors are their own.