@BeforeAll method in super class skipped when it has same name as a @BeforeEach method in subclass

[hjohn]

Steps to reproduce

Given:

package a;

import org.junit.jupiter.api.BeforeAll;

public abstract class A {

    @BeforeAll
    static void before() {
        System.out.println("A");
    }
}

and

package b;

import a.A;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class B extends A {

    @BeforeEach
    void before() {
        System.out.println("B");
    }

    @Test
    void test() {
        System.out.println("Hi there");
    }
}

Executing the test in B prints: B and Hi there. Note the absence of A: the @BeforeAll method was not called. Note that the non-static before method in B does not override the static method (it is in a different package), nor does it conflict with it. Renaming the before method in B or A fixes the problem.

This can easily happen when you have an abstract base class in some utility package, and you are extending it to build tests. If you happen to name a method in this test class that conflicts with a package-private method in the base class, things do not work as expected.

Workaround:

Ensure the names in the base class are sufficiently unique that they're unlikely to have similar names in a subclass.

Deliverables

• A fix for this problem. It probably is a problem with annotation scanning not being thorough enough and not taking this special case into account.

[sbrannen]

Thanks for raising the issue.

I have confirmed that this is a bug.

We'll look into it.

[sbrannen]

At a quick glance, the cause of the issue appears to be due to the fact that org.junit.platform.commons.util.ReflectionUtils.streamMethods(...) first invokes findAllMethodsInHierarchy(...) and then filters based on the isAnnotated(...) predicate afterwards.

Whereas, for such use cases, we would need to apply the predicate while searching the hierarchy for methods. If we did that, b.B.before() would not "hide" a.A.before() which is currently the case.

[sbrannen]

Update: I put together a proof-of-concept fix in #3500.

[sbrannen]

This has been merged into main and backported to 5.10.x.

[sbrannen]

Closely related to:

• Align method and field search algorithms with Java semantics #3553

[sbrannen]

Due to #3600, for 5.10.2 we have decided to revert the changes to our method search algorithm introduced in conjunction with this issue.

However, we will address the issue originally raised in this issue when we resolve #3553 in 5.11.