Come installare JUnit 5 su Ubuntu 22.04 LTS -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 13/04/2026 Pubblicato il: 13/04/2026 17:55 Tempo di lettura: 9 min

Su Ubuntu 22.04 LTS, JUnit 5 non si “installa” come un singolo pacchetto magico: va deciso prima come vuoi usarlo. Se lavori su un progetto Java già gestito da Maven o Gradle, la via corretta è dichiarare la dipendenza nel build file. Se invece ti serve una workstation o una VM di test con i jar disponibili a livello di sistema, puoi appoggiarti ai pacchetti Debian/Ubuntu e al classpath manuale. La differenza conta, perché JUnit 5 è composto da più moduli: Jupiter per i test, Platform per l’esecuzione, e in alcuni casi il supporto al motore di discovery. Trattarlo come un blocco unico porta spesso a classpath incompleti e test che “non partono” senza motivi evidenti.

La scelta pratica è questa: Maven o Gradle se stai sviluppando, pacchetti di sistema se devi fare prove veloci o supportare ambienti dove non vuoi dipendere da un tool di build. In entrambi i casi, il punto non è solo installare, ma verificare che il runtime trovi il motore di test giusto e che la versione di Java sia compatibile. Su Ubuntu 22.04 il punto di partenza sensato è Java 17, che è la baseline naturale per molti progetti moderni e riduce attriti con le versioni recenti di JUnit 5.

Verifica del prerequisito Java su Ubuntu 22.04

Prima di parlare di JUnit, controlla il runtime. Se Java non è presente o è troppo vecchio, il resto della procedura ti farà solo perdere tempo. La verifica minima è questa:

java -version
javac -version

Atteso: una versione 17.x o superiore, con JDK e non solo JRE. Se javac non esiste, installa il JDK. Su Ubuntu 22.04 la scelta pulita è OpenJDK 17:

sudo apt update
sudo apt install -y openjdk-17-jdk

Dopo l’installazione, verifica di nuovo. Se hai più versioni di Java sul sistema, controlla quale è selezionata come default:

sudo update-alternatives --config java
sudo update-alternatives --config javac

Se stai lavorando in produzione o su una macchina condivisa, evita di cambiare il default globale senza motivo. Meglio usare un tool di build che punti esplicitamente al JDK richiesto dal progetto.

Installazione consigliata con Maven

Per un progetto Maven, JUnit 5 si aggiunge nel pom.xml. Qui non serve installare un pacchetto di sistema per il framework: la dipendenza viene risolta da Maven e versionata insieme al progetto. È il metodo più riproducibile, quello che in pratica riduce i problemi quando sposti il repository da una macchina all’altra.

Se il progetto non usa ancora Maven, puoi installarlo così:

sudo apt update
sudo apt install -y maven
mvn -version

Nel pom.xml, la configurazione minima per JUnit 5 è questa:

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.10.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.2.5</version>
        </plugin>
    </plugins>
</build>

Il dettaglio importante è il plugin Surefire. Senza una versione sufficientemente recente, Maven può non eseguire correttamente i test JUnit 5 oppure può comportarsi in modo ambiguo con i motori di test moderni. In pratica: dipendenza giusta, ma test non rilevati. È un classico errore da classpath/tooling, non da codice applicativo.

Per verificare che tutto sia a posto, lancia i test con un caso minimo:

mvn test

Se vuoi un controllo più esplicito, puoi generare un test semplice:

src/test/java/com/example/SampleTest.java

package com.example;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertTrue;

class SampleTest {
    @Test
    void basicAssertionWorks() {
        assertTrue(2 + 2 == 4);
    }
}

Se mvn test termina con BUILD SUCCESS e vedi il test eseguito, l’installazione logica è corretta.

Installazione consigliata con Gradle

Con Gradle la logica è la stessa: il framework si gestisce come dipendenza del progetto. Su Ubuntu 22.04 puoi usare il pacchetto di sistema per avere il comando disponibile, ma nella pratica molti team preferiscono il wrapper ./gradlew perché blocca la versione del tool insieme al repository.

Se ti serve Gradle sul sistema:

sudo apt update
sudo apt install -y gradle
gradle -version

Nel file build.gradle o build.gradle.kts, la configurazione minima è questa:

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
}

test {
    useJUnitPlatform()
}

La riga useJUnitPlatform() è il punto che spesso manca nei progetti migrati da JUnit 4. Senza questa istruzione, Gradle può non attivare il motore corretto e i test non vengono scoperti. Anche qui il sintomo tipico non è un errore di compilazione, ma una suite che parte e non trova nulla.

Per una verifica rapida:

gradle test

Se usi il wrapper:

./gradlew test

In ambienti di team è spesso la soluzione migliore, perché evita differenze tra workstation e CI.

Installazione manuale dei jar su Ubuntu 22.04

La via manuale ha senso solo se hai un caso d’uso preciso: laboratorio, sistema senza Maven/Gradle, prova rapida su una shell remota, oppure integrazione con una pipeline molto custom. In questo scenario, devi scaricare i jar necessari e costruire il classpath a mano. È più fragile, ma utile quando vuoi capire esattamente cosa stai eseguendo.

La cartella di lavoro può essere, per esempio, /opt/junit5:

sudo mkdir -p /opt/junit5
sudo chown -R $USER:$USER /opt/junit5
cd /opt/junit5

Scarica i componenti principali da Maven Central. I file esatti dipendono dalla versione che vuoi usare; qui l’idea è mostrare il flusso, non fissare un URL eterno. Se il download fallisce, controlla la connettività o verifica la versione disponibile sul repository.

wget https://repo1.maven.org/maven2/org/junit/jupiter/junit-jupiter/5.10.2/junit-jupiter-5.10.2.jar
wget https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone/1.10.2/junit-platform-console-standalone-1.10.2.jar

Per l’esecuzione manuale, il jar junit-platform-console-standalone è comodo perché include il necessario per discovery ed execution. È il modo più rapido per far girare test senza configurare altro. Se il tuo obiettivo è solo verificare che JUnit funzioni, questo è il percorso più corto.

Compila un test di esempio e lancialo così:

mkdir -p src/test/java/com/example
cat > src/test/java/com/example/SampleTest.java <<'EOF'
package com.example;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

class SampleTest {
    @Test
    void sumWorks() {
        assertEquals(4, 2 + 2);
    }
}
EOF

javac -cp junit-platform-console-standalone-1.10.2.jar -d out src/test/java/com/example/SampleTest.java
java -jar junit-platform-console-standalone-1.10.2.jar -cp out --scan-classpath

Se tutto è corretto, vedrai il test scoperto ed eseguito. In caso contrario, il primo controllo da fare è il classpath: versione sbagliata del jar, directory di output errata, oppure compilazione fallita perché il compilatore non vede le API JUnit.

Migrazione da JUnit 4 a JUnit 5

Molti ambienti Ubuntu ospitano ancora progetti vecchi che usano JUnit 4. La migrazione non consiste nel sostituire una dipendenza e basta. Cambiano annotazioni, package import, test runner e, in alcuni casi, il modo in cui il build tool scopre i test. Se il repository è fermo da tempo, è facile avere una base che compila ma non esegue la suite come previsto.

Il passaggio minimo è questo: sostituire org.junit.Test con org.junit.jupiter.api.Test, aggiornare le assertion se necessario e assicurarsi che il runner sia JUnit Platform. Se vuoi tenere test vecchi e nuovi insieme durante la transizione, puoi usare il Vintage engine, ma non va lasciato lì “per sempre”: è una stampella, non la destinazione finale.

Un esempio di dipendenza temporanea per supportare test JUnit 4 in un progetto che passa a JUnit 5 è questo:

<dependency>
    <groupId>org.junit.vintage</groupId>
    <artifactId>junit-vintage-engine</artifactId>
    <version>5.10.2</version>
    <scope>test</scope>
</dependency>

Usalo solo se hai test legacy da mantenere durante il refactoring. Se il progetto è nuovo, non ha senso aggiungere Vintage.

Problemi tipici dopo l’installazione

Il problema più comune non è “JUnit non installato”, ma “JUnit installato male rispetto al tool di build”. In pratica i sintomi ricorrenti sono questi: test non scoperti, esecuzione nulla, errore di ClassNotFoundException, oppure compilazione fallita per import mancanti. La diagnosi va fatta guardando il primo errore utile, non l’ultimo messaggio della coda.

Se i test non vengono trovati, controlla:

la presenza di useJUnitPlatform() in Gradle;
una versione recente di Surefire in Maven;
che le classi di test finiscano sotto src/test/java;
che gli import siano di org.junit.jupiter e non di JUnit 4, se la migrazione è già conclusa.

Se il compilatore non trova le API JUnit, il problema è quasi sempre una dipendenza mancante o un classpath incompleto. Con Maven e Gradle la correzione è nel file di build; nella modalità manuale, è il comando javac a dover includere il jar giusto.

Per vedere quali dipendenze effettive sono risolte, usa gli strumenti del build system:

mvn dependency:tree
./gradlew dependencies --configuration testRuntimeClasspath

Questi comandi sono spesso più utili di una ricerca a tentativi nei file di configurazione, perché ti mostrano subito conflitti di versione, esclusioni e moduli transitivi inattesi.

Scelta pratica per un server Ubuntu 22.04 o una macchina di build

Se devi standardizzare una procedura interna, la soluzione più pulita è questa: installa OpenJDK 17, usa Maven o Gradle per i progetti, e riserva l’installazione manuale dei jar ai casi eccezionali. In un contesto team, questo riduce la variabilità, semplifica la CI e rende più facile capire se un problema dipende dal codice o dall’ambiente.

Se stai preparando un server per compilazioni e test, verifica anche lo spazio disco e la memoria. Le suite di test grandi possono consumare più risorse di quanto sembri, soprattutto se generano report, eseguono container di test o avviano database temporanei. Prima di attribuire un fallimento a JUnit, guarda df -h, free -h e i log del job di build.

Infine, tieni separati i livelli: sistema operativo, JDK, build tool e dipendenze del progetto. È una distinzione semplice, ma è quella che evita il classico errore da supporto tecnico: cambiare il sistema quando bastava correggere una riga nel pom.xml o nel build.gradle.

Verifica finale rapida

Se vuoi chiudere con un controllo sintetico, usa questa sequenza:

java -version
mvn test
# oppure
./gradlew test

Atteso: Java 17 disponibile e test JUnit 5 eseguiti correttamente. Se uno di questi passaggi fallisce, la causa va cercata nel livello corrispondente: runtime Java, configurazione del build tool, oppure classpath/manual setup. Non serve complicare la diagnosi: prima si conferma l’ambiente, poi si guarda il progetto, poi si rifinisce la versione di JUnit. Assunzione: su Ubuntu 22.04 LTS hai privilegi sudo e un progetto Java già presente o pronto per essere inizializzato.

Come installare JUnit 5 su Ubuntu 22.04 LTS