Why Maven Doesn’t Find JUnit Tests to Run

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 we’ve included specific tests to run in addition to the standard naming conventions. 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.10.2</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.10.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

4. Incorrect Test Folder

Placing tests in the wrong folder is another reason they 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 source code’s root 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 that 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. In this case, the test phase will be skipped. 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 for the tests to execute on the JUnit 5 platform. Further, we also noted how incorrectly placing 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.