El marco Spring TestContext (que se encuentra en el paquete org.springframework.test.context proporciona soporte general basado en anotaciones para pruebas unitarias y de integración que es independiente del marco de prueba que se utiliza. TestContext El marco también pone mayor énfasis en la convención que en la configuración, con valores predeterminados razonables que se pueden cambiar mediante una configuración basada en anotaciones.

Además de la infraestructura de prueba general, el marco TestContext proporciona soporte explícito para JUnit 4, JUnit Jupiter (también conocido como JUnit 5) y TestNG. Se proporcionan clases auxiliares abstract para JUnit 4 y TestNG Spring. Además, Spring proporciona un Runner especial de JUnit y unas Rules especiales de JUnit para JUnit 4 y una Extensión especial para JUnit Jupiter, que le permiten escribir las llamadas clases de prueba POJO. Las clases de prueba POJO no necesariamente extienden una jerarquía de clases específica, como las clases auxiliares abstract.

La siguiente sección examina brevemente los componentes internos del marco TestContext. Si solo está interesado en utilizar el marco y no necesita ampliarlo con sus propios escuchas o cargadores personalizados, salte directamente a las secciones sobre configuración (administración de contexto, inyección de dependencia, administración de transacciones), clases auxiliares y soporte para anotaciones.

Ver las secciones mencionadas en "Clases auxiliares del marco TestContext".

Abstracciones clave

El núcleo del marco consta de la clase TestContextManager y las interfaces TestContext, TestExecutionListener y SmartContextLoader. Se crea una interfaz TestContextManager para cada clase de prueba (por ejemplo, para ejecutar todos los métodos de prueba dentro de una clase de prueba en JUnit Jupiter). La interfaz TestContextManager, a su vez, administra el TestContext, que contiene el contexto de la prueba actual. La interfaz TestContextManager también actualiza el estado TestContext a medida que se ejecuta la prueba y delega el trabajo a las implementaciones TestExecutionListener que instrumentan la ejecución real de la prueba, proporcionando inyección de dependencia. Gestión de transacciones, etc. La interfaz SmartContextLoader es responsable de cargar el ApplicationContext para una clase de prueba determinada. Para obtener más información y ejemplos de diferentes implementaciones, consulte javadoc y el conjunto de pruebas Spring.

Java webinar

Contexto de prueba

La interfaz TestContext encapsula el contexto en el que se ejecuta la prueba (independientemente del marco de prueba real que se esté utilizando) y proporciona gestión de contexto, así como soporte de almacenamiento en caché para la instancia de prueba de la que es responsable. . La interfaz TestContext también delega en SmartContextLoader la carga del ApplicationContext cuando lo solicite.

TestContextManager

La interfaz TestContextManager es el punto de entrada principal al Spring TestContext Framework y es responsable de administrar un único TestContext y señalar eventos a cada registrado TestExecutionListener en puntos bien definidos ejecución de prueba :

  • Antes de cualquier método "antes de las clases" o "antes de todos" de un marco de prueba en particular.

  • Postprocesamiento de la instancia de prueba.

  • Antes de cualquier método "antes" o "antes de cada" de un marco de prueba en particular.

  • Inmediatamente antes de que se ejecute el método de prueba, pero después de configurar la prueba.

  • Inmediatamente después de ejecutar el método de prueba, pero antes de que se destruya la prueba.

  • Después de cualquier método "después" o "después de cada" de un marco de prueba en particular.

  • Después de cualquier método "después de la clase" o "después de todo" de un marco de prueba en particular.

TestExecutionListener

El oyente TestExecutionListener define una API para responder a los eventos de ejecución de pruebas publicados por el TestContextManager con el que está registrado el oyente. Consulte la configuración de TestExecutionListener.

Cargadores de contexto

ContextLoader es una interfaz de estrategia para cargar ApplicationContext para una prueba de integración administrada por Spring TestContext Framework. Debe implementar SmartContextLoader en lugar de esta interfaz para brindar soporte para clases de componentes, perfiles de definición de beans activos, fuentes de propiedades de prueba, jerarquías de contexto y soporte para WebApplicationContext.

SmartContextLoader es una extensión de la interfaz ContextLoader que reemplaza la simple interfaz SPI ContextLoader original. Específicamente, SmartContextLoader puede elegir manejar ubicaciones de recursos, clases de componentes o inicializadores de contexto. Además, SmartContextLoader puede establecer perfiles de definición de beans activos y probar fuentes de propiedades en el contexto cargado.

Spring proporciona las siguientes implementaciones:

  • DelegatingSmartContextLoader: uno de los dos cargadores predeterminados, delega internamente el trabajo a AnnotationConfigContextLoader, GenericXmlContextLoader o GenericGroovyXmlContextLoader cargadores, dependiendo de la configuración declarada para la clase de prueba o de la presencia de ubicaciones predeterminadas o clases de configuración predeterminadas. La compatibilidad con Groovy está habilitada solo si Groovy está en el classpath.

  • WebDelegatingSmartContextLoader: uno de los dos cargadores predeterminados, delega internamente el trabajo a AnnotationConfigWebContextLoader, GenericXmlWebContextLoader o GenericGroovyXmlWebContextLoader cargadores dependiendo de la configuración declarada para la clase de prueba o de la presencia de ubicaciones predeterminadas o clases de configuración predeterminadas. El cargador web ContextLoader solo se usa si la clase de prueba tiene la anotación @WebAppConfiguration. La compatibilidad con Groovy está habilitada solo si Groovy está en el classpath.

  • AnnotationConfigContextLoader: carga el ApplicationContext estándar de las clases de componentes.

  • AnnotationConfigWebContextLoader: carga el WebApplicationContext de las clases de componentes.

  • GenericGroovyXmlContextLoader: carga un ApplicationContext estándar desde recursos, que son scripts Groovy o archivos de configuración XML.

  • GenericGroovyXmlWebContextLoader: carga WebApplicationContext desde recursos, que son scripts Groovy o archivos de configuración XML.

  • GenericXmlContextLoader: carga el ApplicationContext estándar desde ubicaciones de recursos XML.

  • GenericXmlWebContextLoader: carga WebApplicationContext desde ubicaciones de recursos XML.

Carga inicial del framework TestContext

La configuración predeterminada para los componentes internos de Spring TestContext Framework es suficiente para todos los casos de uso comunes. Sin embargo, hay ocasiones en las que un equipo de desarrollo o un marco de trabajo de terceros necesita cambiar el ContextLoader estándar, implementar un TestContext o un ContextCache personalizado, o complementar los conjuntos estándar de implementaciones ContextCustomizerFactory y TestExecutionListener, etc. Para proporcionar este control de bajo nivel sobre el funcionamiento del marco TestContext, el marco Spring proporciona una estrategia de arranque.

TestContextBootstrapper define una interfaz SPI para cargar el marco TestContext. El TestContextBootstrapper es utilizado por el TestContextManager para cargar implementaciones de TestExecutionListener para la prueba actual y para construir el TestContext que gestiona. Puede configurar una estrategia de arranque personalizada para una clase de prueba (o jerarquía de clases de prueba) especificando la anotación @BootstrapWith directamente o como una metaanotación. Si el programa previo no está configurado explícitamente con la anotación @BootstrapWith, se utiliza el DefaultTestContextBootstrapper o el WebTestContextBootstrapper, dependiendo de la presencia del anotación de código @WebAppConfiguration.

Debido a que es probable que la interfaz SPI TestContextBootstrapper cambie en el futuro (para adaptarse a nuevos requisitos), recomendamos encarecidamente a los desarrolladores que no implementen esta interfaz directamente, sino que extiendan AbstractTestContextBootstrapper o una de sus subclases específicas.