Aggregated TestExecutionListener orders into:
- SpringBootTestExecutionListenerOrder for spring-boot-test module;
- SpringBootAutoConfigureTestExecutionListenerOrder for spring-boot-test-autoconfigure module.
This aggregation helps third-party integrators when choosing the order for a new listener.
I have done two similar PRs in spring-framework and spring-security projects.
Comment From: wilkinsona
Thanks for the proposal. I'd like to see what @sbrannen thinks before we consider merging this into Spring Boot. FWIW, I'm not sure that this should be an enum as, to me, an enum implies a finite set and we may add other listeners in the future.
Comment From: wilkinsona
I've also just noticed that, as proposed, this change introduces a package tangle between org.springframework.boot.test.context and all the packages that define execution listeners. I don't see how that can be avoided as the central location for defining the orders will have to know about every listener and every listener will have to know about the central location to get its order. Unless I've overlooked something and there's a way to break that cycle, I think we'll have to decline this.
Comment From: andreisilviudragnea
@wilkinsona Yes, I saw too the problem with not being able to centralize the listener order of the two modules spring-boot-test and spring-boot-test-autoconfigure.
Maybe at least making the order of each listener statically accessible, through a constant on each listener would work too.
I am working on introducing Mockito Strict Stubbing support to @MockBean-based tests and I found myself digging a lot through the code in order to understand the order of the listeners both in
the Spring TestContext Framework and Spring Boot Test itself.
This order, as you know, is essential to the correct functioning of the framework, but is hidden to anyone who does not really understand how it works. I thought that maybe making it more visible would help other people, apart from me, when trying to extend the existing functionality.
Comment From: andreisilviudragnea
The main idea was to enable someone extending the framework to specify something like "this listener needs to get executed before the ResetMocksTestExecutionListener from Spring Boot Test" with an order relative to the one of ResetMocksTestExecutionListener.
Maybe I overthought this and only extracting each order to a constant on each listener would have been enough.
Comment From: wilkinsona
I"m going to close this one as I can't see a way to centralise the filter ordering without introducing a package tangle. Thanks anyway for the suggestion, @andreisilviudragnea.