¿Hay alguna forma de tener un control completo sobre la ejecución de los métodos de prueba (incluidos los métodos antes/después) en JUnit5, similar a la anotación JUnit4 @RunWith)?
Estoy tratando de construir una extensión JUnit5 Arquillian, pero dado que Aquillian básicamente necesita ejecutar cada prueba en un contenedor, tengo un problema al ejecutar Arquillian desde una extensión Junit5.
Mi código está aquí: BasicJunit5ArquillianTest.java
La prueba debe ejecutar todos los métodos (incluso antes/después) en un contenedor separado, que puede ser una JVM separada, un servidor remoto o integrado o cualquier cosa aislada. Mi extensión ejecuta el método de prueba de beforeEach hook, usando Arquillian para transferir la clase de prueba y ejecutarla en un contenedor usando LauncherFactory.create() , recopila los resultados de la prueba y los transfiere de vuelta.
El problema es que los métodos de prueba se ejecutan dos veces: a través de la ejecución normal de JUnit5 y a través de mi extensión Arquillian desde un anzuelo beforeEach. Me gustaría ejecutar pruebas solo a través de Arquillian y omitir la ejecución normal de los métodos.
¿Es esto posible en una extensión JUnit5? ¿O necesito crear un motor de prueba personalizado, posiblemente ampliando el motor de prueba de Júpiter?
No hay un punto de extensión (¿ todavía ?) que le permita definir dónde o cómo se ejecutan las pruebas. Esto ya es cierto para los subprocesos, lo que significa que no hay forma de ejecutarlos en el subproceso de la aplicación JavaFX o Swing EDT.
Es posible que deba profundizar e implementar un motor, pero eso significa que los usuarios deben elegir entre escribir pruebas de Arquillian o escribir pruebas de Júpiter.
ACTUALIZACIÓN: en una versión más reciente de JUnit 5 lanzada desde que se aceptó esta respuesta, JUnit 5 ahora proporciona el punto de extensión InvocationInterceptor , que es exactamente lo que se necesita para implementar un corredor personalizado como una extensión, que tiene un control total sobre cómo son las pruebas ejecutado e incluso puede reemplazar el cuerpo del método de prueba con algo completamente diferente (por ejemplo, ejecutar la prueba en una JVM diferente y devolver el resultado).