JUnit en Java

Vérifiez qu’une petite méthode renvoie la valeur que vous attendiez. Dans SumCheck.java, gardez un Sum package-private avec add, gardez la classe publique SumCheck, marquez une méthode avec @Test, et appelez assertEquals(5, Sum.add(2, 3));. Quand 2 + 3 vaut 5, le contrôle passe. Une deuxième démo compare Sum.add(4, 5) à 9. Laissez le JAR optionnel pour la page suivante. Cette leçon est un contrôle JUnit avec assertEquals, pas un affichage d’accesseur Records et pas un pipeline Streams.

Un contrôle qui vise 5

Ouvrez SumCheck.java. Gardez le nom de classe publique SumCheck. Supprimez les démos Records Card restantes, les pipelines Pipe Streams restants, les parcours lambda Cue restants et les invites Scanner de Box si elles noient l’histoire JUnit. Le fichier d’enseignement est une classe de test, pas un main qui affiche oak.
Ajoutez les imports en tête de fichier :
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
Gardez un petit helper dans le même fichier :
class Sum {
static int add(int left, int right) {
return left + right;
}
}
Dans SumCheck, écrivez une méthode de test :
@Test
void addsTwoAndThree() {
assertEquals(5, Sum.add(2, 3));
}
@Test marque la méthode comme un contrôle que le runner doit exécuter. assertEquals prend d’abord la valeur attendue, puis la valeur réelle. Ici l’attendu est 5 et le réel est Sum.add(2, 3). Ils correspondent, donc le contrôle passe.

Compilez et lancez ce fichier avec un runner JUnit 5 sur votre classpath — bouton de test de l’IDE, ou launcher console qui sélectionne la classe SumCheck. L’habitude du cours reste « compiler le source du test, puis lancer les contrôles ». Vous ne lancez pas java SumCheck comme programme main ordinaire sur cette page. Vous n’affichez pas t.name(). Vous demandez au runner d’exécuter les méthodes @Test.
Parcourez le contrôle une fois. Sum.add(2, 3) renvoie 5. assertEquals(5, ...) compare ce 5 à l’attendu 5. Ils correspondent. Le contrôle passe. Une ligne de rapport peut montrer un résultat vert ou un court résumé de succès selon le runner. Le fait pédagogique important est que attendu et réel sont d’accord.
Énoncez la règle du débutant en regardant la méthode : @Test marque le contrôle ; assertEquals(expected, actual) compare ; nommez la méthode pour qu’un humain la lise. N’inventez pas de démos d’empaquetage JAR sur cette page. JAR attend la leçon optionnelle suivante. Ne traitez pas un échec contre 9 comme cette première démo — cette première démo vise 5.
Si vous voyez encore oak d’un fichier Records Card restant, passez à SumCheck et gardez assertEquals(5, Sum.add(2, 3));. Si le runner ne trouve aucun test, vérifiez que la méthode a @Test et n’est pas private d’une façon que votre runner rejette.

Un second contrôle qui vise 9

Gardez la même classe publique SumCheck et le même helper Sum. Modifiez le corps du test pour vérifier une autre somme :
@Test
void addsFourAndFive() {
assertEquals(9, Sum.add(4, 5));
}
4 + 5 vaut 9. L’attendu est 9. Le réel est Sum.add(4, 5). Ils correspondent, donc ce contrôle passe aussi. Gardez un contrôle clair par forme pédagogique sur cette page pour que le nombre attendu reste facile à nommer.

Parcourez le contrôle une fois. Sum.add(4, 5) renvoie 9. assertEquals(9, ...) compare attendu et réel. Ils correspondent. Le contrôle passe. Gardez les deux démos comme deux formes pédagogiques. D’abord prouvez un contrôle qui vise 5. Ensuite prouvez un contrôle qui vise 9. Les deux formes partagent les imports JUnit, le helper Sum et @Test.
Si la première démo comparait Sum.add(2, 3) avec 9, le contrôle échouerait car 5 n’est pas 9. Ce programme en échec n’est pas le premier fichier d’enseignement. Le premier fichier d’enseignement vise 5.

JUnit n’est ni Records ni JAR

Les records tenaient des composants compacts que vous affichiez avec des accesseurs. JUnit vérifie un résultat face à une valeur attendue. JAR empaquetera des fichiers de classe pour l’envoi sur une page optionnelle ultérieure. Ne mélangez pas ces trois rôles dans un seul fichier débutant aujourd’hui.
Ici 5 est la valeur attendue dans assertEquals. Ce n’est pas t.n() d’un record Tag et pas un résultat de map stream. Quand un fichier Card restant affiche encore oak, laissez cela comme historique et gardez la ligne d’assertion de SumCheck.
Sans @Test, beaucoup de runners n’exécuteront pas la méthode comme contrôle. Sans assertEquals, vous n’avez pas de comparaison dans cette forme pédagogique. Gardez les deux. Tenez les commandes JAR hors de cette page jusqu’à cette leçon.

Habitudes de runner et de classpath

Les types JUnit vivent dans les packages org.junit.jupiter.api. Votre éditeur ou outil de build doit placer ces jars sur le classpath de compilation et d’exécution. Les débutants collent souvent correctement la classe de test et voient quand même « package does not exist » quand les jars manquent — corrigez le classpath, pas l’orthographe de @Test.
Gardez Sum package-private dans le même fichier pour qu’une seule classe publique reste SumCheck. Gardez les valeurs attendues comme littéraux clairs dans assertEquals. Gardez des noms de méthodes lisibles. Tenez System.out.println ordinaire hors des contrôles pédagogiques sauf pour déboguer vous-même plus tard.
Si la compilation échoue sur org.junit, la ligne import est correcte et la bibliothèque manque du classpath. Si le runner dit zéro test trouvé, cherchez un @Test manquant ou un nom de classe que vous n’avez pas sélectionné.

Vérifications du dossier avant JAR

Listez le dossier après une compilation réussie avec les jars JUnit disponibles. Vous devriez voir SumCheck.class et en général Sum.class à côté du source. Modifiez le source, enregistrez, recompilez, puis lancez les contrôles avec la même habitude de runner. Une classe périmée peut masquer une valeur attendue modifiée si vous sautez la compilation après une édition.
Si javac se plaint de classes publiques en double, gardez seulement SumCheck public. Si un contrôle échoue après avoir saisi assertEquals(9, Sum.add(2, 3)), ce décalage est réel — restaurez la paire correspondante pour la démo que vous voulez garder.
Ne collez pas le record Tag de Card dans SumCheck. Ne remplacez pas assertEquals par stream().map de Pipe. Le travail JUnit optionnel est un contrôle marqué qui compare attendu et réel.

Avant le JAR optionnel

Vous pouvez garder la classe publique SumCheck, garder le helper Sum.add, importer @Test et assertEquals de JUnit, vérifier Sum.add(2, 3) contre 5, puis Sum.add(4, 5) contre 9. Compilez avec JUnit sur le classpath et lancez les contrôles avec un runner JUnit 5. La page optionnelle suivante est JAR.
Gardez les démos SumCheck pour une paire d’assertions claire. Tenez les fichiers Records Card hors de cette page quand vous pratiquez JUnit. Tenez les fichiers Streams Pipe hors de cette page quand vous pratiquez JUnit. Tenez le travail JAR hors de cette page jusqu’à cette leçon. Ces habitudes sont le point de contrôle avant d’avancer. Quand le premier contrôle vise 5 et passe, ou le second vise 9 et passe, JUnit a fait son travail pour cette leçon et vous êtes prêt pour JAR si vous suivez le chemin optionnel.
Un dernier passage dans le dossier : un SumCheck public, Sum package-private, @Test présent, assertEquals(expected, actual) aligné, imports JUnit présents, pas d’attente Scanner, pas de pipeline stream requis. Compilez et lancez les contrôles une fois de plus sur la démo que vous gardez ouverte. Si attendu et réel correspondent encore, la forme JUnit est solide et le cours peut passer au JAR optionnel à la page suivante. Préférez une habitude d’assertion claire par lecture pour que chaque passage enseigne la même carte.