Resolving JUnit Error: Test Class Should Have Exactly One Public Zero-Argument Constructor

1. Overview

When writing unit tests in Java, we may encounter the JUnit error: Test class should have exactly one public zero-argument constructor. This usually happens in JUnit 4 when our test class defines a constructor that takes arguments.

In this tutorial, we’ll focus on how to resolve the error in question. In the coming sections, we’ll show how to fix the error by using parameterized tests, upgrading to JUnit 5, or avoiding parameterized constructors.

2. Understanding the Error

Before running any test method, JUnit normally creates a new instance of the test class so that each test runs independently and doesn’t share state with others. In JUnit 4, to be specific, this process is dependent on finding a public no-argument constructor.

Typically, if a class doesn’t define any constructor, Java automatically provides one, a public no-argument constructor. This implicit constructor is meant to help JUnit 4 instantiate the test class using reflection.

However, the moment we define our own constructor, particularly one that accepts parameters, Java stops generating the default constructor. This ensures that there’s no confusion about which constructor to call when creating an object. When this happens, JUnit 4 can no longer call new TestClass() since the constructor no longer exists, throwing the error in question:

public class ResolvingJUnitConstructorErrorUnitTest {

    private int input;

    // Constructor with a parameter (causes the error)
    public ResolvingJUnitConstructorErrorUnitTest(int input) {
        ...
    }

    @Test
    public void givenNumber_whenSquare_thenReturnsCorrectResult() {
        ...
    }
}

When we consider the example above, JUnit 4 fails to run the test because it doesn’t know what value to provide for the int parameter in our constructor, ResolvingJUnitConstructorErrorUnitTest. Since we don’t use a no-argument constructor, JUnit 4 cannot automatically create an instance before executing the test method.

How JUnit relies on a no-argument constructor is intentional. When we always start with a new, parameter-free instance, JUnit ensures that each test runs independently, eliminating the risk of shared state. For example, it can prevent one test modifying a field that another test later depends on. With this isolation, tests guarantee predictable and repeatable outcomes.

In the event we introduce a parameterized constructor as demonstrated in our example, we disrupt that controlled lifecycle. As a result, JUnit can no longer automatically construct the test class and throws the “Test class should have exactly one public zero-argument constructor” error.

3. Reproducing the Error

In this section, we can use a minimal Maven project to reproduce the error. After that, let’s add JUnit 4 as a dependency inside the project’s pom.xml file:

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.13.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

The code block above adds JUnit as a dependency.

Let’s now create the main class, ResolvingJUnitConstructorError:

public class ResolvingJUnitConstructorError {

    public int square(int a) {
        return a * a;
    }
}

In the class, there’s the square() method for returning the square of a number.

Since our main class is ready, let’s now move on to writing our test class:

public class ResolvingJUnitConstructorErrorUnitTest {

    private int input;

    public ResolvingJUnitConstructorErrorUnitTest(int input) {
        this.input = input;
    }

    @Test
    public void givenNumber_whenSquare_thenReturnsCorrectResult() {
        ResolvingJUnitConstructorError service = new ResolvingJUnitConstructorError();
        assertEquals(input * input, service.square(input));
    }
}

Here, we define a JUnit 4 test called ResolvingJUnitConstructorErrorUnitTest, which includes a constructor that takes an input parameter.

Finally, let’s try running the test:

$ mvn clean test
...
  1. Test class should have exactly one public zero-argument constructor
...

As soon as we do, the build stops before any test methods can run, and we end up getting the expected error message Test class should have exactly one public zero-argument constructor.

4. Resolving the Error in JUnit 4

Here, let’s look at our first solution. In this one, we implement the annotation @RunWith(Parameterized.class) in JUnit 4 to pass parameters to the test class constructor automatically:

@RunWith(Parameterized.class)
public class ResolvingJUnitConstructorErrorUnitTest {

    private final int input;
    private final ResolvingJUnitConstructorError service = new ResolvingJUnitConstructorError();

    public ResolvingJUnitConstructorErrorUnitTest(int input) {
        this.input = input;
    }

    @Parameterized.Parameters
    public static Collection<Object[]> data() {
        return Arrays.asList(new Object[][]{
            {2}, {3}, {4}
        });
    }

    @Test
    public void givenNumber_whenSquare_thenReturnsCorrectResult() {
        assertEquals(input * input, service.square(input));
    }
}

Above, we update our test class to use JUnit 4’s parameterized tests:

• @RunWith(Parameterized.class): instructs JUnit to use the parameterized runner
• @Parameterized.Parameters: defines the collection of inputs, in this case, {2}, {3}, {4}

Let’s see what happens when we run the test again:

$ mvn clean test
... 
[INFO] Results:
[INFO] 
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
...

So, the output above shows that our test now runs three times. In particular, the test runs once for each input value. For every data set ({2}, {3}, {4}), JUnit 4 creates a new instance of the test class, and runs the test separately for each, treating them as independent executions.

With @RunWith(Parameterized.class), JUnit 4 now creates a new instance of the test class for every set of input data. Each instance receives its parameters through the constructor we define.

Here, we fix the issue and also show how JUnit 4 enables parameterized testing through constructor-based injection.

5. Resolving the Issue by Upgrading to JUnit 5

Here, let’s look at our second solution. In this one, we upgrade from JUnit 4 to JUnit 5:

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.14.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

To specify, we add the dependency JUnit Jupiter.

At this point, let’s rewrite our test:

public class ResolvingJUnitConstructorErrorUnitTest {

    private final ResolvingJUnitConstructorError service = new ResolvingJUnitConstructorError();

    @ParameterizedTest
    @ValueSource(ints = {2, 3, 4})
    void givenNumber_whenSquare_thenReturnsCorrectResult(int input) {
        assertEquals(input * input, service.square(input));
    }
}

In the updated example, JUnit 5 simplifies parameterized tests using @ParameterizedTest and @ValueSource:

• @ParameterizedTest: marks the test as parameterized
• @ValueSource(ints = {2, 3, 4}): defines inline test data

Let’s now run the test:

$ mvn clean test
... 
[INFO] Results:
[INFO] 
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
...

Above, the output shows that the test runs three times, the same as before, and all pass successfully. Each input triggers a separate test execution, ensuring isolation between test runs, same as JUnit 4.

By default, JUnit 5 supports parameterized tests without extra configuration. Hence, it removes the need for a public zero-argument constructor and, as a result, makes our test much cleaner and easier to read.

6. Resolving the Issue By Avoiding Parameterized Constructors

Here, let’s look at our third solution. In this one, we don’t use constructors with parameters in the test class. To specify, instead of us passing values through a constructor, we initialize test inputs in setup methods.

Let’s first illustrate this in JUnit 4:

public class ResolvingJUnitConstructorErrorUnitTest {

    private ResolvingJUnitConstructorError service;
    private int input;

    @Before
    public void setUp() {
        service = new ResolvingJUnitConstructorError();
        input = 2; 
    }

    @Test
    public void givenNumber_whenSquare_thenReturnsCorrectResult() {
        assertEquals(input * input, service.square(input));
    }
}

Let’s now look at an example in JUnit 5:

public class ResolvingJUnitConstructorErrorUnitTest {

    private ResolvingJUnitConstructorError service;
    private int input;

    @BeforeEach
    void setUp() {
        service = new ResolvingJUnitConstructorError();
        input = 2; 
    }

    @Test
    void givenNumber_whenSquare_thenReturnsCorrectResult() {
        assertEquals(input * input, service.square(input));
    }
}

In both examples, we use the setup methods @Before in JUnit 4 and @BeforeEach in JUnit 5. To clarify, both methods initialize the service and input fields before each test run.

Now, each test method can focus on asserting the expected outcomes and not on initialization. Additionally, we can now separate test preparation from execution, keeping test methods focused on asserting behavior.

7. Common Mistakes and Best Practices

In the middle of refactoring or introducing dependencies, we can accidentally add a constructor with parameters to a test class. In such a situation, we can apply the JUnit 4 or JUnit 5 solutions discussed earlier to avoid the error Test class should have exactly one public zero-argument constructor.

Other times, we may unintentionally repeat similar test methods that contain small changes in input values. In such an instance, we can consider using parameterized tests instead of duplicating them.

We may also continue writing tests in JUnit 4, even though we may require more boilerplate compared to the alternative. When we’re working with larger projects that may require many tests, migrating to JUnit 5 can make writing parameterized tests easier and reduce repetitive setup.

8. Conclusion

In this article, we examined the JUnit error Test class should have exactly one public zero-argument constructor.

The error usually occurs in JUnit 4 when a test class defines a parameterized constructor. In such an instance, JUnit 4 cannot automatically create an instance of the class before running tests. To demonstrate, we reproduced the problem, explained why it happens, and then provided practical solutions.

In our first solution, we use parameterized tests in JUnit 4 and control the injection of test data, whereas in our second solution, we upgrade to JUnit 5 and provide a cleaner approach. In our third solution, we eliminate the use of parameterized constructors and rely on setup methods, which can make our tests simpler and more maintainable. From understanding the error, we not only help fix test failures but also deepen our insight into how JUnit manages test instantiation and lifecycle.

We can access the source code over on GitHub.