JUnit test methods can't return a value

Question

Why JUnit test methods can't return a value?

Documentation says (emphasis mine):

Test methods and lifecycle methods may be declared locally within the current test class, inherited from superclasses, or inherited from interfaces (see Test Interfaces and Default Methods). In addition, test methods and lifecycle methods must not be abstract and must not return a value.

Why is it enforced like this?

Is this purely a design choice? Is it a best practice?

Answer 1

What is the reasoning behind this?

Think of each test method as being the logical analog of a public static void main(String[]) method in a classic Java application. There needs to be a well known method signature so that the JUnit framework is able to identify the test methods, and call them in a standard way.

As to the specific design points you are querying:

• The reason that the methods cannot be abstract is that they need to be callable. You can't call an abstract method.

• The reason that methods cannot return values is that the test framework would not be able to do anything useful with a returned value. (It would not be impossible to discard any result, but what is the point of a testcase result that can't be used?)

I was thinking maybe we could reuse one test method within another.

If you wanted to reuse code in unit tests, you would just use ordinary methods and other OO features of Java; e.g. base classes, helper classes, etcetera. There are few situations where you would want a free-standing test method and a "component" (for want of a better word) of another test method. And if you did you could write something like this.

    public void test_xxx() {
        real_test_xxx();
    }

    public int real_test_xxx() {
         ...
    }

    public void test_yyy() {
          ...
          res = real_test_xxx()
          ...
    }

Is this purely a design choice? Is it a best practice?

There are no best practices!

These are design choices that are guided by the general requirements and practicalities of unit testing¹. Particularly, the requirement that unit test authors should NOT need to build configurations to tell the test framework what to do.

Note that TestNG takes a similar approach. If a TestNG @Test method is declared as returning a value, it is not treated as a test method; see Can a test method return a value in TestNG

Either way, unless you are proposing to implement yet another Java test framework, this is all moot.

---

^{1 - If there were strong practical reasons for needing abstract test methods or test methods that returned values, someone would have done something about it. The masses (of unit test writers) would rise up and overthrow the tyranical regime (of test framework developers). (Reprise of the "We won't be fooled again" by The Who.)}

Answer 2

Is this purely a design choice?

Yes. In theory, nothing prevents the Junit runner (component thats runs tests of a test class) from accepting as valid a test method with a return value.

Is it a best practice?

Indeed. More you restrict the ways of specifying a unit test method, more you ensure that no misuse happens.

For example look at that simple example that would suppose a test method to return a value.
A addFoo() test method that asserts that the method does what it is expected and that also returns the Foo fixture created :

@Test
public Foo addFoo(){
   Foo foo = new Foo(...);

   // call the api ...
   sut.addFoo(foo); 

   // assertion
   assertEquals(...);

   // return the foo fixture
   return foo;
}

And here a addFooBar() test method that retrieves the Foo fixture created by the previous method and then asserts that the method addFooBar() does what it is expected :

@Test
public void addFooBar(){
   Foo foo = addFoo();
   Bar bar = new Bar(..., foo);

   // call the api ...
   sut.addFooBar(bar); 

   // assertion
   assertEquals(...);
}

That lays multiple issues :

• Does the method addFoo() should be executed multiple times ? It may hurt the test speed execution and make test reports unclear.
• The addFoo() test result may make the addFooBar() test result to fail in spit of a correct implementation.
  How to diagnostic the issue origin ? We added useless complexity.
• The addFoo() test result may make the addFooBar() test result to succeed in spit of a incorrect implementation. Indeed, an incorrect implementation in addFoo() may compensate an incorrect implementation in addFooBar()

Answer 3

One thing I haven't yet seen mentioned is that one of the reasons behind this design decision is historical.

Before test cases where marked by annotations, they were analysed by JUnit via reflection - all public void methods, the name of which started with test, and that didn't have any arguments, were considered test cases that were run by the framework.

Had these methods allowed to also return a value, you could not have created a public helper method starting with test that calculated a value commonly used in some tests, or the framework runner would have tried to run it.

You should have made them private anyway I guess.

Additionally, this was also the high time of "a method name that starts with a verb should do something" (rather than calculate something).

Answer 4

you can write some private methods and reuse them like

@Test
public void test1() {
    privateTest();
}

@Test
public void test2() {
    privateTest();
//    more Logic

}

private int privateTest() {
   return 0;
}

Answer 5

Test methods should be executed independently

If the tests can not run independently then they are not unit tests.

A unit test should not rely on any external state

If test method will return a value, it may applies that test results should be used/relevant to other tests

Same best practice in TestNG

Since TestNG follows best practices for unit testing, which means a unit test method should not have a return value