Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce mechanism for registering default TELs if a custom TEL is registered via @TestExecutionListeners [SPR-8854] #13496

Closed
spring-projects-issues opened this issue Nov 17, 2011 · 1 comment
Assignees
Labels
in: test Issues in the test module type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 17, 2011

Saurabh Chandra opened SPR-8854 and commented

Status Quo

As of Spring Framework 3.2, the TestExecutionListener implementations ServletTestExecutionListener DependencyInjectionTestExecutionListener, DirtiesContextTestExecutionListener, and TransactionalTestExecutionListener are automatically registered by default.

However, if a custom TestExecutionListener is registered via @TestExecutionListeners then the defaults will not be registered. In most common testing scenarios, this effectively forces the user to manually declare all default listeners in addition to any custom listeners, for example:

@TestExecutionListeners(
  {
    MyCustomTestExecutionListener.class,
    ServletTestExecutionListener.class,
    DependencyInjectionTestExecutionListener.class,
    DirtiesContextTestExecutionListener.class,
    TransactionalTestExecutionListener.class
  }
)

The problem with this approach is that it requires that the user know exactly which listeners are registered by default. Moreover, this set can change from release to release -- for example, ServletTestExecutionListener was added in release 3.2.

Proposal

Provide a mechanism for instructing the TestContext framework to register all default TestExecutionListeners in addition to an explicitly configured custom TestExecutionListener.

This could be achieved via a new boolean flag in @TestExecutionListeners. Alternatively, an enum could be introduced that specifies how defaults should be handled -- for example, prepended to custom listeners, appended to customer listeners, or excluded (i.e., the current behavior).

If this proposal is not implemented, it should at least be clearly documented in both Javadoc and the reference manual that the defaults are not prepended by default when specifying a custom TestExecutionListener.


Affects: 3.0 GA

Issue Links:

Referenced from: commits 66250b1

2 votes, 2 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Aug 14, 2014

Sam Brannen commented

Completed as described in the comments for GitHub commit 66250b1:

Support merging custom TELs with default TELs

Prior to this commit, if a custom TestExecutionListener was registered
via @TestExecutionListeners the defaults would not be registered. Thus,
if a user wanted to declare a custom listener and use the default
listeners, the user was forced to manually declare all default
listeners in addition to any custom listeners. This unfortunately
required that the user know exactly which listeners were registered by
default. Moreover, the set of default listeners can change from release
to release, and with the support for automatic discovery of default
listeners introduced in #16092 it is no longer even possible to know
what the set of default TestExecutionListeners is before runtime.

This commit addresses this issue by introducing a mechanism for merging
custom declared listeners with the defaults for the current
environment. Specifically, @TestExecutionListeners supports a new
MergeMode that is used to control whether or not explicitly declared
listeners are merged with the default listeners when
@TestExecutionListeners is declared on a class that does not inherit
listeners from a superclass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: test Issues in the test module type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants