Introduce mechanism for automatic discovery of default TestExecutionListeners [SPR-11466]

[spring-projects-issues]

Rob Winch opened SPR-11466 and commented

Overview

It would be nice if there were a way for a custom TestExecutionListener to register itself as a default TestExecutionListener.

This will be very valuable for the Spring Security test module that is currently in development.

---

Proposal

One idea might be to allow using an SPI discovery of the TestExecutionListener default implementations. Each default TestExecutionListener could declare an @Order annotation to ensure that they are run in the correct order.

---

Affects: 3.0 GA

Issue Links:

• SEC-2587 Improvements in Spring Test ("is depended on by")
• SEC-2700 Register WithSecurityContextTestExecutionListener by default ("is depended on by")
• Document automatic discovery of default TestExecutionListeners in the reference manual [SPR-12082] #16698 Document automatic discovery of default TestExecutionListeners in the reference manual ("is depended on by")
• SEC-2015 Create spring-security-test module
• Introduce mechanism for registering default TELs if a custom TEL is registered via @TestExecutionListeners [SPR-8854] #13496 Introduce mechanism for registering default TELs if a custom TEL is registered via @TestExecutionListeners

Referenced from: commits 66250b1, e753f23, e6d1614

[spring-projects-issues]

Sam Brannen commented

Since this issue contains two proposals, the first of which duplicates #13496, I will revise the summary and description to address only the second proposal.

[spring-projects-issues]

Sam Brannen commented

Rob Winch,

Can you please expound on your thoughts for how such an auto-discovery SPI might work (e.g., properties file in a well known location in the classpath, or...)?

Thanks,

Sam

p.s. why do you have two JIRA accounts: robwinch and rwinch? Could you perhaps merge the former into the latter?

[spring-projects-issues]

Rob Winch commented

I am not too particular how it is implemented so long as Spring Security can automatically register a TestExecutionLitener. I was thinking a properties file to stay consistent with the way the Custom XML namespace handlers are implemented, but again I am not particular.

I'm not sure how I ended up with two usernames. I don't think I am able to do a merge of the users.

[spring-projects-issues]

Rob Winch commented

Another example of adding an additional TestExecutionListener is in Spring Test HtmlUnit to update the HtmlDriver in a Geb test. Keep in mind this is still milestone code, but it might help provide another example. I believe the current thought is this may end up in spring-test as another optional package eventually. This means the adding of the TestExecutionListener might need to be based on the classpath. For an example of using it, see https://github.com/spring-projects/spring-test-mvc-htmlunit/blob/master/mail-webapp/src/test/groovy/org/springframework/test/web/servlet/htmlunit/geb/MockMvcCreateMessagesSpec.groovy

[spring-projects-issues]

Sam Brannen commented

Rob Winch,

I've just pushed working code to my repo: https://github.com/sbrannen/spring-framework/commits/SPR-11466

In summary, the TCF now loads default TestExecutionListener class names from all META-INF/spring-test.default.TestExecutionListeners files present on the classpath. Those listeners are then sorted according to @Order and Ordered. So Spring Security should be able to provide its own such file and have its listeners merged with the defaults from Core Spring.

Please check it out ASAP and let me know if you that suits your needs, and then we can hopefully get it into Spring Framework 4.1 RC2 (which is eminent). ;)

Cheers,

Sam

[spring-projects-issues]

Sam Brannen commented

Update: this feature now makes use of the Properties-based SpringFactoriesLoader mechanism (i.e., META-INF/spring.factories) instead of the custom META-INF/spring-test.default.TestExecutionListeners text file approach.

[spring-projects-issues]

Sam Brannen commented

Implemented as described in the comments for GitHub commit e6d1614:

Support automatic discovery of default TELs

Prior to this commit, there was no declarative mechanism for a custom
TestExecutionListener to be registered as a default
TestExecutionListener.

This commit introduces support for discovering default
TestExecutionListener implementations via the SpringFactoriesLoader
mechanism. Specifically, the spring-test module declares all core
default TestExecutionListeners under the
org.springframework.test.context.TestExecutionListener key in its
META-INF/spring.factories properties file, and third-party frameworks
and developers can contribute to the list of default
TestExecutionListeners in the same manner.

• AbstractTestContextBootstrapper uses the SpringFactoriesLoader to
  look up the class names of all registered default
  TestExecutionListeners and sorts the instantiated listeners using
  AnnotationAwareOrderComparator.

• DefaultTestContextBootstrapper and WebTestContextBootstrapper now
  rely on the SpringFactoriesLoader mechanism for finding default
  TestExecutionListeners instead of hard coding fully qualified class
  names.

• To ensure that default TestExecutionListeners are registered in the
  correct order, each can implement Ordered or declare @Order.

• AbstractTestExecutionListener and all default TestExecutionListeners
  provided by Spring now implement Ordered with appropriate values.

• Introduced "copy constructors" in MergedContextConfiguration and
  WebMergedContextConfiguration

• SpringFactoriesLoader now uses AnnotationAwareOrderComparator
  instead of OrderComparator.