JUnit, 4, 5, Jupiter, Vintage

Después de que se lanzó JUnit 5, muchos desarrolladores simplemente añadieron esta increíble nueva biblioteca a sus proyectos, porque a diferencia de otras versiones, en esta nueva versión, no es necesario migrar de JUnit 4 a 5, solo necesitas incluir la nueva biblioteca en tu proyecto, y con todo el motor de JUnit 5 puedes realizar tus nuevas pruebas utilizando JUnit 5, y las más antiguas con JUnit 4 o 3, seguirán ejecutándose sin problemas.

Pero ¿qué puede pasar en un proyecto grande, un proyecto que se construyó hace 10 años con dos versiones de JUnit funcionando en paralelo?

Nuevos desarrolladores han comenzado a trabajar en el proyecto, algunos de ellos con experiencia en JUnit, otros no. Se crean nuevas pruebas utilizando JUnit 5, se crean nuevas pruebas utilizando JUnit 4, y en algún momento un desarrollador sin conocimiento, al crear un nuevo escenario en una prueba de JUnit 5 que ya ha sido creada, simplemente incluye una anotación de JUnit 4, y la prueba se convierte en una mezcla, algunos @Test de JUnit 4 y algunos @Test de JUnit 5, y cada día es más difícil eliminar la biblioteca de JUnit 4.

Entonces, ¿cómo se resuelve este problema? En primer lugar, necesitas mostrarle a tu equipo qué es de JUnit 5 y qué es de JUnit 4, para que las nuevas pruebas se creen utilizando JUnit 5 en lugar de JUnit 4. Después de eso es necesario seguir la regla del Boy Scout, cada vez que pasen una prueba de JUnit 4 deben migrar a JUnit 5.

Veamos los principales cambios lanzados en JUnit 5. Todo comienza por el nombre, en JUnit 5, no ves paquetes llamados org.junit5, sino más bien org.junit.jupiter. Para resumir, todo lo que ves con “Jupiter” significa que es de JUnit 5. Elegieron este nombre porque Júpiter comienza con “JU” y es el quinto planeta desde el sol.

Otro cambio es respecto a la @Test, esta anotación fue movida a un nuevo paquete: org.junit.jupiter.api y ahora no se utiliza más ningún atributo como “expected” o “timeout”, se usan extensiones en su lugar. Por ejemplo, para el tiempo de espera, ahora tienes una anotación para esto: @Timeout(value = 100, unit = TimeUnit.MILLISECONDS). Otro cambio es que ni los métodos de prueba ni las clases necesitan ser públicos.

Ahora, en lugar de usar @Before y @After en tu configuración de prueba, tienes que usar @BeforeEach y @AfterEach, y también tienes @BeforeAll y @AfterAll. 

Para ignorar pruebas, ahora tienes que usar @Disable en lugar de @Ignore. 

A great news that was released in JUnit 5 was the annotation @ParameterizedTest, with that is possible to run one test multiple times with different arguments. For example, if you want to test a method that creates some object and you want to validate if the fields are filled correctly, you just do the following:

@ParameterizedTest
@MethodSource("getInvalidSources")
void shouldCheckInvalidFields(String name, String job, String expectedMessage) {
	Throwable exception = catchThrowable(() -> new Client(name, job));
  
  	assertThat(exception).isInstanceOf(IllegalArgumentException.class)
      .hasMessageContaining(expectedMessage);
}

static Stream<Arguments> getInvalidSources() {
	return Stream.of(Arguments.arguments("Jean Donato", "", "Job is empty"),
                     Arguments.arguments("", "Dev", "Name is empty"));
}

Hay tantas características interesantes en JUnit 5, te recomiendo revisar la Guía de Usuario de JUnit 5, para analizar lo que es útil para tu proyecto.

Ahora que todos los desarrolladores saben qué se cambió en JUnit 5, pueden comenzar el proceso de eliminación de JUnit 4 de su proyecto. Así que, si aún estás usando JUnit 4 en 2024, y tu proyecto es grande, probablemente tengas algunas dependencias que usan JUnit 4. Te recomiendo analizar tus bibliotecas para verificar si algunas de ellas están utilizando JUnit 4.

En la imagen de abajo estoy usando el Analizador de Dependencias de IntelliJ.

Como puedes ver, jersey-test está utilizando JUnit 4, es decir, incluso si elimino JUnit 4 de mi proyecto, JUnit 4 estará disponible para usar debido a Jersey. La forma más fácil será actualizar jersey a 2.35 porque JUnit 5 se introdujo en jersey-test 2.35, pero no puedo actualizar el marco de jersey-test porque otras bibliotecas se romperán en mi proyecto. Entonces, en este caso, ¿qué puedo hacer?

I can exclude JUnit from Jersey with Dependency Exclusions from Maven (like the image below). That way JUnit 4 will not be used anymore, but rather our JUnit 5. 

Cuando ejecutes algunas pruebas que usen Jersey, no se cargarán, porque hay métodos en Jersey que utilizan anotaciones de JUnit 4, setUp y tearDown, usando @Before y @After. Para resolver esto, puedes crear una “Clase de Configuración” que extienda JerseyTest implementando setUp y tearDown con @BeforeEach y @AfterEach llamando a super.setUp() y super.TearDown().

public class JerseyConfigToJUnit5 extends JerseyTest {

  @BeforeEach
  public void setUp() throws Exception {
  	super.setUp();
  }
  
  @AfterEach
  public void tearDown() throws Exception {
  	super.tearDown();
  }
}

this textSo, si ya has verificado tus bibliotecas y nadie depende más de JUnit 4, finalmente puedes migrar todas tus pruebas a JUnit 5, para este proceso, hay una herramienta excelente que te ahorra mucho trabajo, es OpenRewrite, un ecosistema de refactorización automática para el código fuente, ellos cambiarán todos tus paquetes antiguos, las viejas anotaciones, y todo al nuevo.

Ya está, muchachos, ahora tú y tus compañeros pueden disfrutar de JUnit 5 y relajar la mente sabiendo que las nuevas pruebas se crearán con JUnit 5 y el proyecto no se convertirá en un Frankestein. Así que, recuerda, mantén tu proyecto actualizado, porque si olvidas tus bibliotecas, cada día será más difícil actualizar, siempre usa especificaciones, y marcos de trabajo que sigan las especificaciones, y tener un buen diseño en tu código, esto te permite cambiar y moverte con facilidad.