Interface TestExecutionListener

All Known Subinterfaces:
AotTestExecutionListener
All Known Implementing Classes:
AbstractDirtiesContextTestExecutionListener, AbstractTestExecutionListener, ApplicationEventsTestExecutionListener, BeanOverrideTestExecutionListener, CommonCachesTestExecutionListener, DependencyInjectionTestExecutionListener, DirtiesContextBeforeModesTestExecutionListener, DirtiesContextTestExecutionListener, EventPublishingTestExecutionListener, MockitoResetTestExecutionListener, ServletTestExecutionListener, SqlScriptsTestExecutionListener, TransactionalTestExecutionListener

public interface TestExecutionListener
TestExecutionListener defines a listener API for reacting to test execution events published by the TestContextManager with which the listener is registered.

Note that not all testing frameworks support all lifecycle callbacks defined in this API. For example, the beforeTestExecution and afterTestExecution callbacks are not supported in conjunction with JUnit 4 when using the SpringMethodRule.

This interface provides empty default implementations for all methods. Concrete implementations can therefore choose to override only those methods suitable for the task at hand.

Concrete implementations must provide a public no-args constructor, so that listeners can be instantiated transparently by tools and configuration mechanisms.

Implementations may optionally declare the position in which they should be ordered among the chain of default listeners via the Ordered interface or @Order annotation. See TestContextBootstrapper.getTestExecutionListeners() for details.

Wrapping Behavior for Listeners

The TestContextManager guarantees wrapping behavior for multiple registered listeners that implement lifecycle callbacks such as beforeTestClass, afterTestClass, beforeTestMethod, afterTestMethod, beforeTestExecution, and afterTestExecution. This means that, given two listeners Listener1 and Listener2 with Listener1 registered before Listener2, any before callbacks implemented by Listener1 are guaranteed to be invoked before any before callbacks implemented by Listener2. Similarly, given the same two listeners registered in the same order, any after callbacks implemented by Listener1 are guaranteed to be invoked after any after callbacks implemented by Listener2. Listener1 is therefore said to wrap Listener2.

For a concrete example, consider the relationship between the TransactionalTestExecutionListener and the SqlScriptsTestExecutionListener. The SqlScriptsTestExecutionListener is registered after the TransactionalTestExecutionListener, so that SQL scripts are executed within a transaction managed by the TransactionalTestExecutionListener.

Registering TestExecutionListener Implementations

A TestExecutionListener can be registered explicitly for a test class, its subclasses, and its nested classes by using the @TestExecutionListeners annotation. Explicit registration is suitable for custom listeners that are used in limited testing scenarios. However, it can become cumbersome if a custom listener needs to be used across an entire test suite. This issue is addressed through support for automatic discovery of default TestExecutionListener implementations through the SpringFactoriesLoader mechanism. Specifically, default TestExecutionListener implementations can be registered under the org.springframework.test.context.TestExecutionListener key in a META-INF/spring.factories properties file.

Spring provides the following implementations. Each of these implements Ordered and is registered automatically by default.

Since:
2.5
Author:
Sam Brannen, Juergen Hoeller
See Also:
  • Method Summary

    Modifier and Type
    Method
    Description
    default void
    Post-processes a test class after execution of all tests within the class.
    default void
    Post-processes a test immediately after execution of the test method in the supplied test context — for example, for timing or logging purposes.
    default void
    Post-processes a test after execution of after lifecycle callbacks of the underlying test framework — for example, by tearing down test fixtures.
    default void
    Pre-processes a test class before execution of all tests within the class.
    default void
    Pre-processes a test immediately before execution of the test method in the supplied test context — for example, for timing or logging purposes.
    default void
    Pre-processes a test before execution of before lifecycle callbacks of the underlying test framework — for example, by setting up test fixtures.
    default void
    Prepares the test instance of the supplied test context — for example, to inject dependencies.