junit: impacto de forkMode = "once" en la corrección de la prueba

Question

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

estoy pensando en cambiar a forkMode="once" pero estoy seguro si esto va a acoplar las pruebas alguna manera y tal vez me dan falsos negativos y/o positivos falsos resultados después de ejecutar mis pruebas.

Preguntas:

1. Será cada caso de prueba obtener un nuevo cargador de clases de manera que todas las referencias estáticas de ciclos anteriores no son accesibles/visible ya?

2. ¿Hay otras cosas que conducen a probar la dependencia/acoplamiento de métodos de ensayo que pueden cambiar el comportamiento (al lado de carga de la biblioteca nativa que no estoy utilizando)

3. ¿Qué pasa con la basura recogida/finalización, son ellos correr después de cada prueba? (No dependen de ellos, pero sólo quiero obtener una imagen completa)

ACTUALIZACIÓN

De acuerdo con las respuestas actuales parece que junit siempre está compartiendo un único cargador de clases entre todos los casos de prueba por vm/fork al usar forkMode. (así forkMode = "una vez" significa que hay un cargador de clases para todas las pruebas)

Esto tiene muchas ventajas (pruebas más rápidas y pueden causar fallas en las pruebas debido al acoplamiento estático) pero también algunas desventajas (acoplamiento estático que solo funcionará Si se utiliza un cargador de clase compartida -> falso positivo)

Answer 1

1. El corredor de prueba realizará de manera efectiva una única serie de todas sus pruebas y las ejecutará, de modo que solo esté involucrado 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 te obligará a reducir el acoplamiento estático entre las cláusulas, lo cual es una buena idea.
3. Generalmente no hay ningún CG explícito, pero puede hacerlo usted mismo.

En general, ejecutar todas las pruebas en una VM es algo bueno. Te obliga a mirar el acoplamiento estático y es mucho más rápido. Fundamentalmente, también es la forma en que su IDE los ejecutará, y esa es realmente la forma en que las pruebas deben ejecutarse, lo más cerca posible a la frecuencia que compila.

Answer 2

en cuanto a Stefan's blog entry sobre este me atrevería a decir:

1. sólo obtendrá un único cargador de clases para forkMode = "una vez"
2. se no tendrá acceso al enviro Ant ya no
3. el GC se realizará dentro del GC engendrado (si forceMode = "una vez") y esto significa que NO es después de que se ejecute cada prueba.

Answer 3

Tenga en cuenta que el modo predeterminado forma una VM nueva para cada caso de prueba (es decir, clase) no para cada prueba (es decir, método). En la aplicación que estoy probando hay problemas que surgen cuando reutilizo una máquina virtual para más de una prueba: los objetos y el estado quedan sobrantes de las pruebas anteriores y detienen el funcionamiento posterior. 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 notoriamente difícil asegurar que se llame en cualquier momento dado en cualquier caso.