I have encountered a test issue which is introduced by a third party lib- togglz which registers a Spring Test TestExecutionListener by default, but I do not want to use this Listener at all, it will affect my mocking codes on the beans(based on the classes/interfaces from this lib).

How to disable it globally?

I know JUnit 5 itself has a solution to exclude a JUnit Platform TestExecutionListener via a property junit.platform.execution.listeners.deactivate in a junit-platform.properties file.

But I cannot find a similar solution in Spring framework or Spring Boot.

Comment From: simonbasle

This is loaded by factory loading mechanism (SpringFactoriesLoader) in the TestContextBootsrapper. By design it discovers implementations to load. There's no way to explicitly exclude specific factories from being discovered that way.

So there's currently no central way of doing exactly what you ask.

Perhaps I can offer a workaround in the case of Spring Test execution listeners: default factories are defined in TestContextBootsrapper#getDefaultTestExecutionListeners(), which is a protected method.

So you could override that method, create a new List from the super one (which is unmodifiable) and remove the togglz instance from the list.

You will need to use your custom implementation of TestContextBootstrapper via the @BootstrapWith annotation on all test classes where the togglz listener causes any issue.

Side note: that mechanism ends up being used by TestContextManager#getTestExecutionListeners() which returns a modifiable List, but I think it would be even harder to remove the togglz listener at this level.

Perhaps @sbrannen will have further insight.

Comment From: hantsy

@simonbasle Thanks for this useful hint.

Comment From: snicoll

IMO this should be reported against togglz. If the behaviour is intrusive for your use cases, they may be better suited to provide a recommendation and/or adapt their own listener.

I don't think we should pursue this.

Comment From: hantsy

If possible to add a excludes attribute to @TestExecutionListeners, and provides a property like JUnit 5 to disable it at load time.

Comment From: hantsy

@snicoll Yeah, I have reported this issue on togglz Github issues, https://github.com/togglz/togglz/issues/997, and also provided a PR to move the listener to a standalone module.

But it seems I am not in the same page with the togglz maintainer.

Comment From: sbrannen

If possible to add a excludes attribute to @TestExecutionListeners, and provides a property like JUnit 5 to disable it at load time.

We've never had support for disabling individual listeners (TestExecutionListener), and we also don't have support for disabling individual context customizer factories (ContextCustomizerFactory).

Rather, in the Spring TestContext Framework we recommend that listeners and customizer factories "only do something when they're supposed to do something."

That principle can be seen in several implementations within Spring Framework and across the Spring portfolio.

For example, TransactionalTestExecutionListener does not start or manage transactions unless the test class or test method is annotated with @Transactional.

Similarly, The MockServerContainerContextCustomizerFactory/MockServerContainerContextCustomizer implementation does not create a MockServerContainer unless the Jakarta WebSocket API is present on the classpath and the test class is annotated with @WebAppConfiguration.

Whereas, TogglzTestExecutionListener (almost?) always modifies the internal state of a FeatureManager bean, if present in the ApplicationContext.

To best support users with varying use cases, TogglzTestExecutionListener should only modify the state of a bean in the ApplicationContext if the user requests that -- for example, via a Togglz-specific annotation on the test class.

Phrased differently, the mere presence of the TogglzTestExecutionListener in the classpath should not result in the state of a bean in the ApplicationContext being modified automatically without the user requesting that.

In light of that, I am closing this issue, and I'll add a note to the related Togglz issue.