DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Integrating AWS With Salesforce Using Terraform
  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Knowing and Valuing Apache Kafka’s ISR (In-Sync Replicas)
  • SRE vs. DevOps

Trending

  • Integrating AWS With Salesforce Using Terraform
  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Knowing and Valuing Apache Kafka’s ISR (In-Sync Replicas)
  • SRE vs. DevOps
  1. DZone
  2. Coding
  3. Java
  4. Maven Plugin Testing - In a Modern way - Part II

Maven Plugin Testing - In a Modern way - Part II

Karl Heinz Marbaise user avatar by
Karl Heinz Marbaise
·
Sep. 02, 20 · Tutorial
Like (1)
Save
Tweet
Share
2.81K Views

Join the DZone community and get the full member experience.

Join For Free

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
x
16
 
1
@MavenJupiterExtension
2
class SeveralMavenIT {
3

          
4
  @MavenTest
5
  void the_first_test_case(MavenExecutionResult result) {
6
     ...
7
  }
8
  @MavenTest
9
  void the_second_test_case(MavenExecutionResult result) {
10
     ...
11
  }
12
  @MavenTest
13
  void the_third_test_case(MavenExecutionResult result) {
14
     ...
15
  }
16
}


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

Plain Text
 
xxxxxxxxxx
1
16
 
1
.
2
└── src/
3
    └── test/
4
        └── resources-its/
5
            └── org/
6
                └── it/
7
                    └── SeveralMavenIT/
8
                        ├── the_first_test_case/
9
                        │   ├── src/
10
                        │   └── pom.xml
11
                        ├── the_second_test_case/
12
                        │   ├── src/
13
                        │   └── pom.xml
14
                        └── the_this_test_case/
15
                            ├── src/
16
                            └── pom.xml


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

Plain Text
 
xxxxxxxxxx
1
33
 
1
.
2
└──target/
3
   └── maven-it/
4
       └── org/
5
           └── it/
6
               └── SeveralMavenIT/
7
                   ├── the_first_test_case/
8
                   │   ├── .m2/
9
                   │   ├── project/
10
                   │   │   ├── src/
11
                   │   │   ├── target/
12
                   │   │   └── pom.xml
13
                   │   ├── mvn-stdout.log
14
                   │   ├── mvn-stderr.log
15
                   │   └── other logs
16
                   ├── the_second_test_case/
17
                   │   ├── .m2/
18
                   │   ├── project/
19
                   │   │   ├── src/
20
                   │   │   ├── target/
21
                   │   │   └── pom.xml
22
                   │   ├── mvn-stdout.log
23
                   │   ├── mvn-stderr.log
24
                   │   └── mvn-arguments.log
25
                   └── the_third_test_case/
26
                       ├── .m2/
27
                       ├── project/
28
                       │   ├── src/
29
                       │   ├── target/
30
                       │   └── pom.xml
31
                       ├── mvn-stdout.log
32
                       ├── mvn-stderr.log
33
                       └── mvn-arguments.log


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
xxxxxxxxxx
1
 
1
  @MavenTest
2
  void the_first_test_case(MavenExecutionResult result) {
3
     
4
  }


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
xxxxxxxxxx
1
 
1
assertThat(result).isSuccessful();


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
xxxxxxxxxx
1
 
1
assertThat(result).isFailure();


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
xxxxxxxxxx
1
 
1
assertThat(result)
2
    .isSuccessful()
3
    .out()
4
    .warn().isEmpty();


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
xxxxxxxxxx
1
21
 
1
@MavenJupiterExtension
2
class FirstIT {
3
  void base_test (MavenExecutionResult result) {
4
    assertThat(result)
5
        .isSuccessful()
6
        .out()
7
        .info()
8
        .containsSubsequence(
9
            "--- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-maven) @ kata-fraction ---",
10
            "--- jacoco-maven-plugin:0.8.5:prepare-agent (default) @ kata-fraction ---",
11
            "--- maven-resources-plugin:3.1.0:resources (default-resources) @ kata-fraction ---",
12
            "--- maven-compiler-plugin:3.8.1:compile (default-compile) @ kata-fraction ---",
13
            "--- maven-resources-plugin:3.1.0:testResources (default-testResources) @ kata-fraction ---",
14
            "--- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ kata-fraction ---",
15
            "--- maven-surefire-plugin:3.0.0-M4:test (default-test) @ kata-fraction ---",
16
            "--- maven-jar-plugin:3.2.0:jar (default-jar) @ kata-fraction ---",
17
            "--- maven-site-plugin:3.9.1:attach-descriptor (attach-descriptor) @ kata-fraction ---"
18
        );
19
  }
20
}
21

          


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
xxxxxxxxxx
1
 
1
assertThat(result)
2
    .isSuccessful()
3
    .out()
4
    .warn()
5
    .contains("JAR will be empty - no content was marked for inclusion!");


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

Java
xxxxxxxxxx
1
27
 
1
@MavenJupiterExtension
2
class FailureIT {
3

          
4
  @MavenTest
5
  void basic_configuration_checking_logout(MavenExecutionResult result) {
6
    assertThat(result)
7
        .isSuccessful()
8
        .out()
9
        .info()
10
        .containsSubsequence(
11
            "--- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-maven) @ basic_configuration_checking_logout ---",
12
            "--- jacoco-maven-plugin:0.8.5:prepare-agent (default) @ basic_configuration_checking_logout ---",
13
            "--- maven-resources-plugin:3.1.0:resources (default-resources) @ basic_configuration_checking_logout ---",
14
            "--- maven-compiler-plugin:3.8.1:compile (default-compile) @ basic_configuration_checking_logout ---",
15
            "--- maven-resources-plugin:3.1.0:testResources (default-testResources) @ basic_configuration_checking_logout ---",
16
            "--- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ basic_configuration_checking_logout ---",
17
            "--- maven-surefire-plugin:3.0.0-M4:test (default-test) @ basic_configuration_checking_logout ---",
18
            "--- maven-jar-plugin:3.2.0:jar (default-jar) @ basic_configuration_checking_logout ---",
19
            "--- maven-site-plugin:3.9.1:attach-descriptor (attach-descriptor) @ basic_configuration_checking_logout ---"
20
        );
21
    assertThat(result)
22
        .isSuccessful()
23
        .out()
24
        .warn()
25
        .contains("JAR will be empty - no content was marked for inclusion!");
26
  }
27
}


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
xxxxxxxxxx
1
 
1
Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!


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.

integration test Apache Maven Test case Java (programming language) Plain text

Opinions expressed by DZone contributors are their own.

Trending

  • Integrating AWS With Salesforce Using Terraform
  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Knowing and Valuing Apache Kafka’s ISR (In-Sync Replicas)
  • SRE vs. DevOps

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: