1. Overview
When working with Maven projects, it’s common for a developer to make a mistake that results in JUnit tests not running during a build. There are a variety of reasons why Maven might not find JUnit tests to run. In this tutorial, we’ll look at those specific cases and see how to fix them.
2. Naming Conventions
Maven Surefire plugin executes unit tests during the test phase of the Maven build lifecycle. Importantly, the Surefire plugin is called implicitly by the Maven life cycle whenever the test goal is executed — for example, when running ‘mvn test‘ or ‘mvn install‘.
By default, the Surefire Plugin will automatically include all the test classes with the following wildcard patterns:
- “**/Test*.java” – includes all of its subdirectories and all Java filenames that start with “Test”
- “**/*Test.java” – includes all of its subdirectories and all Java filenames that end with “Test”
- “**/*Tests.java” – includes all of its subdirectories and all Java filenames that end with “Tests”
- “**/*TestCase.java” – includes all of its subdirectories and all Java filenames that end with “TestCase”
So, if our tests don’t follow the above wildcard patterns, Maven isn’t going to pick these tests to run. However, there are cases where there could be project-specific naming patterns to be followed instead of these standard conventions. In those cases, we can override the Surefire Plugin by explicitly specifying the tests that we want to include (or exclude) and other patterns.
For example, let’s consider the following pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M7</version>
<configuration>
<includes>
<include>**/*_UT.java</include>
</includes>
<excludes>
<exclude>**/BaseTest.java</exclude>
<exclude>**/TestsUtil.java</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
Here, we can see that in addition to the standard naming conventions, we’ve included specific tests to run. Also, we’ve excluded certain naming patterns that instruct the plugin not to consider those tests during the test phase.
3. Incorrect Dependencies
When using the JUnit 5 platform, we need to add at least a single TestEngine implementation. For example, if we want to write tests with JUnit Jupiter, we need to add the test artifact junit-jupiter-engine to the dependencies in pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M7</version>
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.4.0</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
If we want to write and execute JUnit 3 or 4 tests via the JUnit Platform, we need to add the Vintage Engine to the dependencies section:
<dependencies>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<version>5.4.0</version>
<scope>test</scope>
</dependency>
</dependencies>
4. Incorrect Test Folder
Placing tests in the wrong folder is another reason why the tests aren’t considered for execution. This occurs mainly due to the default class creation path setting in some IDEs (such as Eclipse).
To give some background, Maven defines a standard directory structure:
- src
- main
- java
- resources
- webapp
- test
- java
- resources
- target
The main directory is the root directory for source code related to the application itself, not the test code. The test directory contains the test source code. Any tests placed under the src/main/java directory will be skipped. Instead, all the tests and test resources should be placed under the src/test /java and src/test/resources folder, respectively.
For example, the source class file should be placed here:
src/main/java/Calculator.java
And, the corresponding test class file should be placed here:
src/test/java/CalculatorTest.java
5. Test Method Not public
The default access modifier in Java is package-private. This means that all classes created without additional access modifiers are visible only to the classes in the same package. Some IDEs have standard configurations so that, while creating tests, they will be marked as package-private. Also, the test method could have been marked as private by mistake.
Until JUnit 4, Maven will only run the test classes which are marked as public. We should note, though, that this won’t be an issue with JUnit 5+. However, the actual test methods should always be marked as public.
Let’s look at an example:
public class MySampleTest {
@Test
private void givenTestCase1_thenPrintTest1() {
...
}
}
Here, we can notice that the test method is marked as private. Consequently, Maven won’t consider this method for test execution. Marking the test method as public will enable the test to run.
6. Packaging Type
Maven provides multiple options to package the application. The popular packaging types are jar, war, ear, and pom. If we don’t specify a packaging value, it will default to jar packaging. Each packaging contains a list of goals to bind to a particular phase.
Marking the packaging type as pom will only bind goals to the deploy and install phases. The test phase will be skipped in this case. This could be one of the cases where the tests don’t run as expected.
Sometimes, due to a copy-paste error, the Maven packaging type could’ve been marked as pom:
<packaging>pom</packaging>
To fix this, we need to specify the correct packaging type. For example:
<packaging>jar</packaging>
7. Conclusion
In this article, we examined specific cases in which Maven doesn’t find JUnit tests to run.
First, we saw how the naming conventions could impact the test execution. Next, we discussed the dependencies to add for the tests to execute on the JUnit 5 platform. Further, we also noted how incorrect placement of tests in a different folder or having private test methods could prevent the tests from being run. Finally, we saw how the packaging type is bound to specific goals in each phase.
