DEV Community

Karl Heinz Marbaise
Karl Heinz Marbaise

Posted on

Maven Plugin Testing - In a Modern way - Part III

#programming #java #maven #testing

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 behaviour.

Let us begin with the following basic integration test (we ignore the project which is used for testing at the moment.)

@MavenJupiterExtension
class BaseIT {

  @MavenTest
  void the_first_test_case(MavenExecutionResult result) {
     ...
  }
}
Enter fullscreen mode Exit fullscreen mode

The above test will execute Apache Maven by using the following options by default:

  • --batch-mode
  • --show-version
  • --errors

That means that each execution within the Integration Testing Framework will be done like this:

mvn --batch-mode --show-version --errors
Enter fullscreen mode Exit fullscreen mode

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:

.
└──target/
   └── maven-it/
       └── org/
           └── it/
               └── FirstMavenIT/
                   └── the_first_test_case/
                       ├── .m2/
                       ├── project/
                       │   ├── src/
                       │   ├── target/
                       │   └── pom.xml
                       ├── mvn-stdout.log
                       ├── mvn-stderr.log
                       └── mvn-arguments.log
Enter fullscreen mode Exit fullscreen mode

The option -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:

mvn -Dmaven.repo.local=<Directory> --batch-mode --show-version --errors package
Enter fullscreen mode Exit fullscreen mode

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):

@MavenJupiterExtension
class FailureIT {
  ...
  @MavenTest
  @MavenOption(MavenCLIOptions.DEBUG)
  void basic_configuration_with_debug(MavenExecutionResult result) {
    assertThat(result)
        .isSuccessful()
        .out()
        .info()
        .containsSubsequence(
            "--- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-maven) @ basic_configuration_with_debug ---",
            "--- jacoco-maven-plugin:0.8.5:prepare-agent (default) @ basic_configuration_with_debug ---",
            "--- maven-resources-plugin:3.1.0:resources (default-resources) @ basic_configuration_with_debug ---",
            "--- maven-compiler-plugin:3.8.1:compile (default-compile) @ basic_configuration_with_debug ---",
            "--- maven-resources-plugin:3.1.0:testResources (default-testResources) @ basic_configuration_with_debug ---",
            "--- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ basic_configuration_with_debug ---",
            "--- maven-surefire-plugin:3.0.0-M4:test (default-test) @ basic_configuration_with_debug ---",
            "--- maven-jar-plugin:3.2.0:jar (default-jar) @ basic_configuration_with_debug ---",
            "--- maven-site-plugin:3.9.1:attach-descriptor (attach-descriptor) @ basic_configuration_with_debug ---"
        );
    assertThat(result)
        .isSuccessful()
        .out()
        .warn()
        .containsSubsequence(
            "Neither executionException nor failureException has been set.",
            "JAR will be empty - no content was marked for inclusion!");

    assertThat(result)
        .isSuccessful()
        .out()
        .debug()
        .containsSubsequence(
            "Created new class realm maven.api",
            "Project: com.soebes.itf.maven.plugin.its:basic_configuration_with_debug:jar:1.0",
            "Goal:          org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources (default-resources)"
        );

  }
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

So based on turning on debugging output it means that you can check debugging output like this:

assertThat(result)
    .isSuccessful()
    .out()
    .debug()
    .containsSubsequence(
        "Created new class realm maven.api",
        "Project: com.soebes.itf.maven.plugin.its:basic_configuration_with_debug:jar:1.0",
        "Goal:          org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources (default-resources)"
    );
Enter fullscreen mode Exit fullscreen mode

If you like to have the --batch-mode option, --show-version as well as the --error option back in your test case have to add them like this:

  @MavenTest
  @MavenOption(MavenCLIOptions.BATCH_MDOE)
  @MavenOption(MavenCLIOptions.SHOW_VERSION)
  @MavenOption(MavenCLIOptions.ERRORS)
  @MavenOption(MavenCLIOptions.DEBUG)
  void basic_configuration_with_debug(MavenExecutionResult result) {
  ...
  }
Enter fullscreen mode Exit fullscreen mode

The result will be that your Maven command line now looks like before including the supplemental --debug option:

mvn -Dmaven.repo.local=<Directory> --batch-mode --show-version --errors --debug package
Enter fullscreen mode Exit fullscreen mode

That shows that you can easily combine several command line options for a test case via the @MavenOption annotation.

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:

  @MavenTest
  @MavenOption(QUIET)
  @MavenOption(SHOW_VERSION)
  @MavenOption(value = LOG_FILE, parameter = "test.log")
  void basic_configuration_with_debug(MavenExecutionResult result) {
  ...
  }
Enter fullscreen mode Exit fullscreen mode

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):

  @MavenTest
  @MavenOption(MavenCLIOptions.QUIET)
  @MavenOption(MavenCLIOptions.SHOW_VERSION)
  @MavenOption(value = MavenCLIOptions.LOG_FILE, parameter = "test.log")
  void basic_configuration_with_debug(MavenExecutionResult result) {
  ...
  }
Enter fullscreen mode Exit fullscreen mode

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:

@MavenJupiterExtension
@MavenOption(MavenCLIOptions.FAIL_AT_END)
@MavenOption(MavenCLIOptions.NON_RECURSIVE)
@MavenOption(MavenCLIOptions.ERRORS)
@MavenOption(MavenCLIOptions.DEBUG)
class FailureIT {

  @MavenTest
  void case_one(MavenExecutionResult project) {
    ..
  }

  @MavenTest
  void case_two(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  void case_three(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  void case_four(MavenExecutionResult result) {
    ..
  }

}
Enter fullscreen mode Exit fullscreen mode

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:

@MavenJupiterExtension
@MavenOption(MavenCLIOptions.FAIL_AT_END)
@MavenOption(MavenCLIOptions.NON_RECURSIVE)
@MavenOption(MavenCLIOptions.ERRORS)
@MavenOption(MavenCLIOptions.DEBUG)
class FailureIT {

  @MavenTest
  void case_one(MavenExecutionResult project) {
    ..
  }

  @MavenTest
  void case_two(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  void case_three(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  @MavenOption(MavenCLIOptions.DEBUG)
  void case_four(MavenExecutionResult result) {
    ..
  }

}
Enter fullscreen mode Exit fullscreen mode

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:

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RUNTIME)
@Inherited
@MavenOption(MavenCLIOptions.FAIL_AT_END)
@MavenOption(MavenCLIOptions.NON_RECURSIVE)
@MavenOption(MavenCLIOptions.ERRORS)
@MavenOption(MavenCLIOptions.DEBUG)
public @interface MavenTestOptions {
}
Enter fullscreen mode Exit fullscreen mode

This meta annotation can now being used to change the test class of the previous example like this:

@MavenJupiterExtension
@MavenTestOptions
class FailureIT {

  @MavenTest
  void case_one(MavenExecutionResult project) {
    ..
  }

  @MavenTest
  void case_two(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  void case_three(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  @MavenOption(MavenCLIOptions.DEBUG)
  void case_four(MavenExecutionResult result) {
    ..
  }

}
Enter fullscreen mode Exit fullscreen mode

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.):

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RUNTIME)
@Inherited
@MavenJupiterExtension
@MavenOption(MavenCLIOptions.FAIL_AT_END)
@MavenOption(MavenCLIOptions.NON_RECURSIVE)
@MavenOption(MavenCLIOptions.ERRORS)
@MavenOption(MavenCLIOptions.DEBUG)
public @interface MavenTestOptions {
}
Enter fullscreen mode Exit fullscreen mode

Based on that we can change the test case to look like this:

@MavenTestOptions
class FailureIT {

  @MavenTest
  void case_one(MavenExecutionResult project) {
    ..
  }

  @MavenTest
  void case_two(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  void case_three(MavenExecutionResult result) {
    ..
  }

  @MavenTest
  @MavenOption(MavenCLIOptions.DEBUG)
  void case_four(MavenExecutionResult result) {
    ..
  }

}
Enter fullscreen mode Exit fullscreen mode

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.

Oldest comments (0)

Read next

abhayit2000 profile image

Addressing the Challenges and Limitations of Selenium WebDriver

Abhay Chaturvedi -

ssukhpinder profile image

Day 23 of 30-Day .NET Challenge: Span<T> over Arrays

Sukhpinder Singh -

harsh_dev26 profile image

Choosing Your Path: Frontend, Backend, or Full-Stack Development?

Harsh Mriduhash -

wadecodez profile image

Inertia.js Does not Work

Wade Zimmerman -