JUnit, 4, 5, Jupiter, Vintage

Dopo il rilascio di JUnit 5, molti sviluppatori hanno semplicemente aggiunto questa fantastica nuova libreria ai loro progetti, perché rispetto alle altre versioni, in questa nuova versione non è necessario migrare da JUnit 4 a 5, basta includere la nuova libreria nel progetto, e con tutto il motore di JUnit 5 è possibile fare i nuovi test utilizzando JUnit 5, e quelli vecchi con JUnit 4 o 3, continueranno a funzionare senza problemi.

Ma cosa può accadere in un grande progetto, un progetto costruito 10 anni fa con due versioni di JUnit che funzionano in parallelo?

I nuovi sviluppatori hanno iniziato a lavorare sul progetto, alcuni di loro con esperienza in JUnit, altri no. Vengono creati nuovi test utilizzando JUnit 5, altri test utilizzando JUnit 4, e a un certo punto uno sviluppatore senza conoscenza, quando creerà un nuovo scenario in un test JUnit 5 già esistente, incluirà semplicemente un’annotazione JUnit 4, e il test diventerà una mescolanza di @Test di JUnit 4 e @Test di JUnit 5, e ogni giorno diventa più difficile rimuovere la libreria JUnit 4.

Allora, come si risolve questo problema? Innanzitutto, è necessario mostrare alla tua squadra cosa è di JUnit 5 e cosa è di JUnit 4, così che i nuovi test vengano creati utilizzando JUnit 5 invece di JUnit 4. Dopo di ciò è necessario seguire la regola del Boy Scout, ogni volta che passano un test JUnit 4 devono migrare a JUnit 5.

Vediamo le principali modifiche rilasciate in JUnit 5. Tutto inizia dal nome, in JUnit 5 non si vedono più pacchetti chiamati org.junit5, ma piuttosto org.junit.jupiter. Per riassumere, tutto ciò che vedete con “Jupiter” significa che è da JUnit 5. Hanno scelto questo nome perché Jupiter inizia con “JU” ed è il quinto pianeta dal sole.

Un’altra modifica riguarda l’@Test, questa annotazione è stata spostata in un nuovo pacchetto: org.junit.jupiter.api e ora non si utilizza più nessun attributo come “expected” o “timeout”, ma si utilizzano estensioni al loro posto. Per esempio, per il timeout, ora avete un’annotazione specifica per questo: @Timeout(value = 100, unit = TimeUnit.MILLISECONDS). Un’altra modifica è che né i metodi di test né le classi devono essere pubblica.

Ora, invece di utilizzare @Before e @After nella vostra configurazione di test, dovete utilizzare @BeforeEach e @AfterEach, e avete anche @BeforeAll e @AfterAll. 

Per ignorare i test, ora dovete utilizzare @Disable invece di @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"));
}

Ci sono molte caratteristiche interessanti in JUnit 5, vi consiglio di consultare il Manuale dell’utente di JUnit 5, per analizzare cosa è utile per il vostro progetto.

Ora che tutti gli sviluppatori sanno cosa è stato modificato in JUnit 5, puoi iniziare il processo di rimozione di JUnit 4 dal tuo progetto. Quindi, se stai ancora utilizzando JUnit 4 nel 2024 e il tuo progetto è un grande progetto, probabilmente avrai alcune dipendenze che utilizzano JUnit 4. Ti consiglio di analizzare le tue librerie per verificare se alcune di esse stanno utilizzando JUnit 4.

Nell’immagine qui sotto sto utilizzando Dependency Analyzer da IntelliJ.

Come puoi vedere, jersey-test sta utilizzando JUnit 4, cioè, anche se rimuovo JUnit 4 dal mio progetto, JUnit 4 sarà disponibile per l’uso perché Jersey. Il modo più facile sarà aggiornare jersey alla versione 2.35 perché JUnit 5 è stato introdotto in jersey-test 2.35, ma non posso aggiornare il framework jersey-test perché altre librerie si romperanno nel mio progetto. Quindi, in questo caso, cosa posso fare?

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. 

Quando esegui alcuni test che utilizzano Jersey, non saranno caricati, perché ci sono metodi in Jersey che utilizzano le annotazioni JUnit 4, setUp e tearDown, utilizzando @Before e @After. Per risolvere questo, puoi creare una “Classe di Configurazione” che estende JerseyTest implementando setUp e tearDown con @BeforeEach e @AfterEach chiamando super.setUp() e super.TearDown().

public class JerseyConfigToJUnit5 extends JerseyTest {

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

Allora, se hai già controllato le tue librerie e nessuno ha più dipendenze da JUnit 4, finalmente puoi migrare tutti i tuoi test a JUnit 5, per questo processo, c’è uno strumento molto utile che ti risparmia molto lavoro, è OpenRewrite, un ecosistema di refactoring automatico per il codice sorgente,他们将改变你所有的旧包，旧的注解, e tutto il resto alla nuova versione.

È tutto ragazzi, ora tu e i tuoi compagni di squadra potete godervi JUnit 5 e rilassare la mente sapendo che i nuovi test saranno creati con JUnit 5 e il progetto non diventerà unmostro. Quindi, ricorda, mantieni il tuo progetto aggiornato, perché se dimentichi le tue librerie, ogni giorno sarà sempre più difficile aggiornare, sempre usa le specifiche e i framework che le seguono, e avere un buon design nel tuo codice, questo ti permette di cambiare e muoverti con facilità.