In some scenarios running spring test (via gradle test runner) yields "no tests found", even though the actual problem is a simple missing dependency / configuration.
I verified this issue occurs with (at least): spring-boot: 2.4.5, 2.5.1, 2.5.2 spring: 5.3.7, 5.3.8, 5.3.9 gradle: 7.x
The issue only occurs in specific constellations, eg removing one configuration may yield an explicit / clear exception about the missing dependency, removing another one may yield "no tests found" instead.
Unfortunately I cannot provide an isolated test / example as of now. Is there anything else I can do to acquire more information that may hint to root cause of this issue?
Comment From: masc3d
looking at --debug output of gradle, I see the error leading up to "no tests found" is merely logged as a warning
2021-07-23T12:03:42.822+0200 [DEBUG] [TestEventLogger] 12:03:42.822 [Test worker] WARN o.s.w.c.s.GenericWebApplicationContext - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.deku.leoz.node.service.internal.NodeAuthorizer': Unsatisfied dependency expressed through field 'bundleInstaller'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'sx.packager.BundleInstaller' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@javax.inject.Inject()}
Comment From: wilkinsona
Assuming that you're using JUnit 5, the creation of the application context is triggered by Spring Framework's org.springframework.test.context.junit.jupiter.SpringExtension. Any failure to create the context should result in an exception being thrown to JUnit and the tests failing. It sounds like you have a situation where that exception is being swallowed. If you can recreate the problem locally, I would try doing so with the debugger attached to see what's going on. A good starting point would be the catch block in org.springframework.context.support.AbstractApplicationContext.refresh() from where the warning message above is logged. Stepping out from there to see what happens to the rethrown exception may help to identify what's going on.
Comment From: masc3d
thanks for the insight and hint. I have been looking at stacks when they hit the warning in AbstractApplicationContext.refresh()
both outcomes (explicit error and reporting no tests found) have exactly the same stack at this point 🤷🏻♂️
Comment From: wilkinsona
While the stacks are the same, there may be some state that's different and this is altering the behaviour. If you step out (or over) from the point where the exception is rethrown hopefully the point at which the behaviour diverges will become apparent.
Comment From: masc3d
thanks @wilkinsona I have traced it, the cause was an application event listener exiting the process instantly on ApplicationFailedEvent. As this listener may or may not have been registered at the time of dependency error, results seemed inconsistent.
Comment From: masc3d
closing, as issue was not directly related to spring.
Comment From: wilkinsona
Thanks for letting us know, @masc3d. I'm glad to hear that you got to the bottom of it.