java - results - junit: impacto de forkMode="una vez" en la corrección de la prueba

testing jenkins

Question

Me gustaría reducir el tiempo que nuestra compilación (usando ant) ​​toma para ejecutar las pruebas. Actualmente estoy usando el forkMode defecto, que forkMode una nueva vm en cada clase de prueba ( perTest ).

Estoy pensando en cambiar a forkMode="once" pero no estoy seguro de si esto va a emparejar las pruebas y tal vez me dé resultados positivos falsos y / o negativos después de realizar mis pruebas.

Preguntas:

1. ¿Cada caso de prueba obtendrá un nuevo ClassLoader para que todas las referencias estáticas de ejecuciones anteriores ya no sean accesibles / visibles?

2. ¿Hay otras cosas que llevan a probar la dependencia / acoplamiento de los métodos de prueba que pueden cambiar el comportamiento (además de la carga de la biblioteca nativa que no estoy usando)?

3. ¿Qué pasa con la recolección / finalización de basura, se ejecutan después de cada prueba? (No confío en ellos, pero solo quiero obtener una imagen completa)

ACTUALIZAR

Según las respuestas actuales, parece que junit siempre está compartiendo un único cargador de clases entre todos los casos de prueba por vm / fork cuando se usa forkMode. (entonces forkMode = "once" de hecho significa que hay un cargador de clases para todas las pruebas)

Esto tiene muchas ventajas (pruebas más rápidas y puede hacer que las pruebas fallen debido al acoplamiento estático) pero también algunas desventajas (el acoplamiento estático que solo funcionará si se usa un cargador de clases compartido -> falso positivo)

Answer 1

1. El corredor de pruebas realizará efectivamente una única Suite de todas sus pruebas y las ejecutará, de modo que solo participe un cargador de clases.
2. Sí, eso significa que los datos estáticos se compartirán entre las pruebas, lo que ocasionalmente puede ser útil, pero lo obligará a reducir el acoplamiento estático entre las cláusulas, lo cual es bueno.
3. Generalmente no hay GC explícito, pero puedes hacer el tuyo.

En general, ejecutar todas las pruebas en una máquina virtual es algo bueno. Te obliga a mirar el acoplamiento estático y es mucho más rápido. De manera crucial, también es la forma en que su IDE los ejecutará, y esa es realmente la forma en que se deben ejecutar las pruebas, lo más cerca posible de la frecuencia de compilación.

Answer 2

Mirando la entrada del blog de Stefan sobre esto, me atrevería a adivinar:

1. solo obtendrá un cargador de clase única para forkMode = "once"
2. Ya no tendrás acceso al entorno Ant.
3. el GC se realizará dentro del GC generado (si forceMode = "once") y esto significa que NO después de que se ejecuta cada prueba.

Answer 3

Tenga en cuenta que el modo predeterminado establece una nueva VM para cada caso de prueba (es decir, clase), no para cada prueba (es decir, método). En la aplicación que estoy probando actualmente hay problemas que surgen cuando reutilizo una máquina virtual para más de una prueba: los objetos y el estado se quedan de las pruebas anteriores y dejan de funcionar las posteriores. Esto puede no ser un problema si su aplicación está bien estructurada y sus pruebas son estrictamente autónomas. Dudo que la recolección de basura se ejecute automáticamente después de cada prueba: es muy difícil garantizar que se llame en cualquier momento dado en cualquier caso.