Mockito verification sees 0 interactions in a PER_CLASS lifecycle, multi-threaded, SpringBootTest context - mockito

Question

I am running a test case where a mock's behavior is stubbed in the BeforeAll of a PER_CLASS test suite. The subject under test (in my boiled-down reproducer below) is a pool of worker threads which all interact with the mock. I then run multiple Test functions, each of which makes assertions about different expected effects of having run the thread pool. One such test verifies that the mock is invoked at least n times before a timeout. This test always fails because Mockito says there are 0 interactions with the mock. However, there are clearly interactions with the mock, because other test cases that rely on this interaction pass.
The Mockito docs say that mocks are thread-safe, but warns that multiple threads cannot stub and verify against a shared mock:
However Mockito is only thread-safe in healthy tests, that is tests without multiple threads stubbing/verifying a shared mock. Stubbing or verification of a shared mock from different threads is NOT the proper way of testing because it will always lead to intermittent behavior.
I'm not setting more than one stub and certainly not in multiple threads. When I debug my test case, it shows that the same thread actually performs both the stubbing and verification. I do not think I'm running afoul of this warning, then.
This SO answer suggests that there is a bug in Mockito (since 2017), but when I read through the Github issues, it looks like the issue is with argument captors, not with timeout or verify. I don't think this is the root cause, unless I'm overlooking something obvious.
I have written a reproducer below. It's a SpringBootTest case because that's the context in which I first encountered the issue, but I may try removing SpringBoot from the equation next. I have found a few interesting facts:
The verify step only fails in the PER_CLASS lifecycle; PER_METHOD works.
The PER_CLASS lifecycle test will succeed if I move the stubbing from the #BeforeClass to the #Test. (PER_METHOD works either way).
public class MyTest {
#Nested
#SpringBootTest(classes = MyBean.class)
#TestInstance(TestInstance.Lifecycle.PER_CLASS)
public class MyPerClassTest {
#Autowired public MyBean bean;
#MockBean public Runnable runnable;
private final AtomicInteger counter = new AtomicInteger();
#BeforeAll
public void setup() {
Mockito.doAnswer(context -> {
counter.incrementAndGet();
return null;
}).when(runnable).run();
// Start a thread pool of workers that invoke the runnable.
bean.start();
}
#Test
public void isInvoked() {
// Fails: 0 interactions.
Mockito.verify(runnable, Mockito.timeout(10_000).atLeast(16)).run();
}
#Test
public void counterGoesUp() {
// Succeeds: the mock increments the counter as expected, because it is invoked.
Awaitility.await()
.atMost(FIVE_SECONDS)
.until(() -> counter.get() >= 16);
}
}
#Nested
#SpringBootTest(classes = MyBean.class)
#TestInstance(TestInstance.Lifecycle.PER_METHOD) // the default
public class MyPerMethodTest {
#Autowired public MyBean bean;
#MockBean public Runnable runnable;
private final AtomicInteger counter = new AtomicInteger();
#BeforeEach
public void setup() {
Mockito.doAnswer(context -> {
counter.incrementAndGet();
return null;
}).when(runnable).run();
// Start a thread pool of workers that invoke the runnable.
bean.start();
}
#Test
public void isInvoked() {
// Passes.
Mockito.verify(runnable, Mockito.timeout(10_000).atLeast(16)).run();
}
#Test
public void counterGoesUp() {
// Passes.
Awaitility.await()
.atMost(FIVE_SECONDS)
.until(() -> counter.get() >= 16);
}
}
}
I'm not sure why PER_CLASS fails. If anyone is familiar with why, please let me know. Thanks.