Paquetages, diagrammes de classes et tests unitaires en Java

Un paquetage regroupe des classes et des interfaces liées sous un même nom. Il sépare aussi les noms : deux classes appelées Parcel peuvent coexister lorsque leurs noms de paquetages diffèrent. Un paquetage fournit à Java une frontière d’accès ainsi qu’un moyen d’organiser les fichiers.

Déclarer le paquetage en premier

Un fichier source ordinaire commence par sa déclaration de paquetage, suivie des importations puis de la classe. Des commentaires peuvent précéder la déclaration. Par exemple :

package com.example.parcels.domain;

public class Parcel {
    private int weightGrams;

    public Parcel(int weightGrams) {
        this.weightGrams = weightGrams;
    }
}

Tout type de premier niveau dans ce fichier appartient à com.example.parcels.domain. Un fichier comporte au plus une déclaration de paquetage. La classe publique Parcel doit se trouver dans Parcel.java ; changer uniquement le répertoire ne modifie pas le paquetage déclaré.

Transformer les points en répertoires

La racine des sources est le répertoire où commence le chemin du paquetage. Dans un projet Maven ou Gradle standard, le code Java principal commence dans src/main/java. Remplace chaque point du nom du paquetage par une barre oblique, puis ajoute le nom de la classe :

src/main/java/
  com/example/parcels/domain/Parcel.java

Le paquetage est com.example.parcels.domain, et non src.main.java.com.example.parcels.domain. Les trois premiers répertoires correspondent à l’organisation de la construction ; ils ne font pas partie du nom Java. Lorsqu’un environnement de développement signale une incohérence de paquetage, compare la déclaration au chemin sous la racine des sources. Déplace le fichier ou corrige la déclaration pour les faire correspondre.

Les noms de paquetages utilisent des lettres minuscules. Les organisations inversent généralement leur domaine : example.com devient com.example, suivi du projet et de sa partie concernée. Un projet sans domaine peut utiliser parcels.domain. Si une partie du domaine inversé contient un trait d’union, remplace-le par un trait de soulignement, comme dans org.example.hyphenated_name. Évite l’espace de noms java et javax de la plateforme.

Utiliser le nom complet de la classe

Un nom pleinement qualifié réunit le nom du paquetage et le nom simple de la classe : com.example.parcels.domain.Parcel. Il identifie la classe même lorsqu’un autre paquetage possède aussi une classe Parcel. Le code peut désigner une classe accessible par son nom complet sans importation :

java.util.ArrayList<String> names = new java.util.ArrayList<>();

Pour exécuter une classe principale appartenant à un paquetage, donne son nom complet et un chemin de classes pointant vers la racine de l’arborescence des paquetages compilés. Depuis le répertoire du projet :

javac -d out src/main/java/com/example/parcels/Main.java src/main/java/com/example/parcels/domain/Parcel.java
java -cp out com.example.parcels.Main

Ici, javac -d out crée l’arborescence de sortie et java -cp out recherche à partir de sa racine. Lancer java Main depuis un répertoire de paquetage fait perdre la partie de l’identité de la classe correspondant au paquetage. Les outils de construction et les environnements de développement gèrent normalement ces commandes.

Distinguer les paquetages voisins

com.example.parcels et com.example.parcels.domain sont des paquetages distincts. Le partage d’un préfixe de nom ne donne aucun droit d’accès supplémentaire. Un fichier sans déclaration appartient au paquetage sans nom. Les paquetages nommés ne peuvent pas importer ses classes : utilise donc des paquetages nommés dans tout programme comportant plusieurs parties.

Une importation permet à un fichier source d’utiliser le nom simple d’un type accessible. Elle indique au compilateur ce que désigne le nom. Elle ne copie pas la classe, ne télécharge pas de bibliothèque et ne rend pas publique une classe masquée.

Lire le début d’un fichier source

L’interface utilisateur appartient à un paquetage et utilise des classes de deux autres :

package com.example.parcels.ui;

import com.example.parcels.domain.Parcel;
import com.example.parcels.domain.ShippingCalculator;
import java.util.Scanner;

public class TextUI {
    private Scanner scanner;
    private ShippingCalculator calculator;
}

Parcel et ShippingCalculator viennent du paquetage du domaine du programme ; Scanner vient de la bibliothèque Java. Chaque importation s’applique uniquement à ce fichier. Un autre fichier qui utilise Scanner doit avoir sa propre importation ou employer le nom complet java.util.Scanner.

Choisir un type unique ou un caractère générique

import java.util.Scanner; est une importation d’un type unique. La classe exacte est visible pour le lecteur. import java.util.*; est une importation avec caractère générique : les types accessibles de ce paquetage peuvent être désignés par leur nom lorsqu’ils sont utilisés. Le caractère générique ne charge pas les classes inutilisées dans le programme et ne le ralentit pas.

Le caractère générique s’arrête à ce paquetage. Il n’inclut pas java.util.function.Function ni java.util.stream.Collectors, qui se trouvent dans des paquetages distincts. La même règle s’applique à ton propre code : import com.example.parcels.*; n’atteint pas com.example.parcels.domain.Parcel.

Trois cas ne nécessitent aucune importation : les types du même paquetage, les types de java.lang disponibles automatiquement et les types désignés par leur nom complet. C’est pourquoi String, System, Math, Integer et Object apparaissent couramment sans importation.

Résoudre un conflit de noms simples

java.util et java.awt possèdent tous deux une classe appelée List. Deux importations d’un type unique pour ces classes différentes provoquent une erreur de compilation. Deux importations avec caractère générique peuvent coexister, mais le nom simple List devient ambigu lorsqu’il est utilisé. Une importation d’un type unique est prioritaire sur une importation avec caractère générique.

Si les deux classes sont nécessaires, importe l’une et écris le nom complet de l’autre :

import java.util.List;

class NameDisplay {
    private List<String> names;
    private java.awt.List widget;
}

Les importations Java ne proposent pas de syntaxe d’alias telle que import ... as .... Le nom pleinement qualifié permet de distinguer le second type.

Importer un membre statique

Une importation statique permet d’appeler un membre statique sans le nom de la classe à laquelle il appartient :

import static java.lang.Math.sqrt;

Le fichier peut maintenant appeler sqrt(16.0). Le code de test utilise souvent import static org.junit.jupiter.api.Assertions.assertEquals; pour que les assertions se lisent comme des vérifications directes. Dans le code ordinaire du programme, utilise les importations statiques avec discernement afin que les lecteurs puissent toujours voir d’où viennent les opérations.

Suivre les indications de l’erreur

« Cannot find symbol » peut indiquer une importation manquante ou un type mal orthographié. « Package ... does not exist » oriente vers un problème d’orthographe du paquetage, de racine des sources ou de dépendance. « Is not public ... cannot be accessed from outside package » signifie que Java a trouvé le type, mais que l’accès est bloqué. Ajouter une autre importation ne peut pas corriger cette erreur d’accès ; examine la déclaration de la classe et les membres dont tu as besoin.

Un paquetage doit exposer les classes et les méthodes dont les autres parties ont besoin tout en masquant les détails d’implémentation. Les modificateurs d’accès permettent de faire respecter cette frontière. Une importation peut raccourcir un nom, mais elle ne peut pas franchir une frontière fermée par les règles d’accès de Java.

Choisir l’accès à un membre de classe

Sans modificateur, les membres ordinaires d’une classe et ses constructeurs ont un accès de paquetage. Ce n’est pas un mot-clé nommé default. Une classe de premier niveau n’a que deux possibilités : publique ou avec un accès de paquetage. Une classe publique de premier niveau est stockée dans un fichier portant son nom, comme ShippingCalculator.java.

Vérifier le type et l’opération

Supposons que l’interface utilisateur doive construire un colis. Une classe publique ne suffit pas à elle seule :

package com.example.parcels.domain;

public class Parcel {
    private int weightGrams;

    Parcel(int weightGrams) {
        this.weightGrams = weightGrams;
    }
}

Le constructeur a un accès de paquetage. Le code de com.example.parcels.ui peut désigner Parcel, mais ne peut pas appeler new Parcel(1200). Rends ce constructeur public si la création de colis fait partie du service public du paquetage. Garde weightGrams privé et expose une opération adaptée au lieu d’ouvrir l’accès au champ.

L’accès de paquetage tient compte du nom complet du paquetage. Un paquetage qui semble parent ou enfant n’est pas le même paquetage. Le code de com.example.parcels n’a aucun accès particulier aux éléments auxiliaires de com.example.parcels.domain.

Comprendre l’accès protégé

protected autorise l’accès depuis les classes sans lien de parenté du paquetage déclarant ainsi que depuis les sous-classes. Entre paquetages, l’accès à un membre d’instance passe par le contexte d’héritage de la sous-classe. Une sous-classe peut utiliser son propre champ hérité, mais ne peut pas utiliser un objet quelconque de la superclasse pour contourner la frontière du paquetage.

Par exemple, si Item déclare protected int weightGrams, une classe Letter extends Item située dans un autre paquetage peut utiliser this.weightGrams. Dans Letter, un paramètre dont le type est simplement Item ne permet pas d’utiliser item.weightGrams ; une référence de type Letter permet l’accès au membre hérité. Cette restriction évite que les privilèges d’une sous-classe deviennent un accès général à chaque Item.

Masquer délibérément les éléments auxiliaires

Rends ShippingCalculator et feeInCents publics si l’interface utilisateur les appelle. Une classe auxiliaire WeightBands peut garder un accès de paquetage. Le code extérieur au paquetage du domaine dépend alors du comportement du calculateur, pas de la façon dont il stocke le tableau. Remplacer cette classe auxiliaire demande moins de modifications ailleurs.

Les tests peuvent utiliser le même nom de paquetage que la classe testée tout en se trouvant sous src/test/java. Cela leur donne un accès de paquetage sans placer le code de test parmi les fichiers de production. Cela ne donne pas accès aux champs privés. Rendre chaque membre public uniquement pour satisfaire un test multiplie les dépendances aux éléments internes ; teste plutôt le comportement public ou une opération utile à l’échelle du paquetage.

Un diagramme de classes UML montre la structure statique : les classes, leurs membres et leurs relations. Il aide le lecteur à voir quels types d’objets existent et ce qu’ils proposent. Il ne suit pas l’ordre des appels de méthodes pendant l’exécution.

Lire les trois compartiments

Une boîte de classe comporte le nom de la classe en haut, les attributs au milieu et les opérations en bas. Un attribut représente généralement un champ Java ; une opération représente la signature visible d’une méthode. Une esquisse peut omettre les compartiments qui ne servent pas son objectif.

Pour un colis, voici une représentation textuelle de la boîte :

Parcel
-----------------------------
- weightGrams: int
- recipient: String
-----------------------------
+ Parcel(weightGrams: int, recipient: String)
+ getWeightGrams(): int
+ isHeavierThan(limitGrams: int): boolean

Le constructeur porte le nom de la classe et n’a pas de type de retour. La méthode isHeavierThan accepte un entier nommé limitGrams et renvoie un booléen.

Traduire l’ordre des noms et des types

UML place le nom avant le type : weightGrams: int. Java place le type en premier : int weightGrams. Une opération suit le même ordre, avec le nom en premier pour les paramètres, puis place le type de retour après sa parenthèse fermante.

private int weightGrams;

public boolean isHeavierThan(int limitGrams) {
    return weightGrams > limitGrams;
}

Ce code correspond à - weightGrams: int et à + isHeavierThan(limitGrams: int): boolean. Le corps d’une méthode est généralement absent du diagramme ; l’opération indique ce qui peut être appelé, pas l’algorithme.

Préserver la visibilité et les marques particulières

Les symboles de visibilité sont + public, - private, # protected et ~ accès de paquetage. Place le symbole avant le nom du membre. Si un diagramme fourni omet un symbole, n’invente pas sa visibilité ; ajoute le symbole voulu lorsque tu documentes du code.

Un membre statique est souligné. Il appartient à la classe plutôt qu’à chaque objet. Une classe ou une opération abstraite est écrite en italique ou marquée {abstract} lorsque l’italique est peu pratique. La marque abstraite signifie qu’une sous-classe doit fournir le comportement manquant avant qu’un objet puisse être créé à partir d’une classe concrète.

Une boîte d’interface porte «interface» au-dessus de son nom. Par exemple, ParcelRepository peut proposer + save(parcel: Parcel): void et + findAll(): List<Parcel>. La boîte indique un contrat ; elle ne choisit pas d’implémentation du stockage.

Choisir le détail dont le lecteur a besoin

Une esquisse de planification peut ne montrer que Parcel, Shipment et leurs principales opérations. Un diagramme destiné à implémenter une classe doit indiquer les types et la visibilité. Énumérer chaque accesseur courant peut masquer les relations que le diagramme devait montrer. Sélectionne les membres utiles et garde-les cohérents avec le code : un champ Java privé ne doit pas apparaître avec le symbole public + et une méthode statique doit être soulignée.

Une association montre un lien structurel entre des objets. En Java, un objet conserve généralement une référence vers un autre dans un champ. Le trait peut aussi indiquer combien d’objets sont autorisés et dans quel sens la référence peut être suivie.

Compter depuis l’extrémité opposée

La multiplicité se trouve à côté de la classe dont elle dénombre les objets. Si 1..* apparaît à côté de Parcel et 1 à côté de Shipment, une expédition possède un ou plusieurs colis et chaque colis appartient à exactement une expédition. Lis chaque extrémité séparément, en partant d’un objet situé à l’extrémité opposée.

Une référence unique peut représenter 1 ou 0..1 ; une collection représente une extrémité pouvant comporter plusieurs objets. Une List Java seule n’impose pas de borne inférieure. Un Shipment soumis à une règle de 1..* colis doit rejeter une liste initiale vide et empêcher les opérations ultérieures de la vider. De même, une référence unique obligatoire doit être vérifiée pour exclure null.

Suivre la référence

Une flèche ouverte à l’extrémité Parcel signifie qu’une référence peut être suivie de Shipment vers Parcel. Un diagramme de classes peut laisser la navigabilité non précisée. Dans la convention pédagogique utilisée ici, les flèches indiquent les références à sens unique ; un trait sans symbole peut signifier un accès bidirectionnel ou une direction non précisée. Ne déduis pas l’existence d’un champ inverse de la seule présence d’une flèche vers Parcel.

Un nom de rôle tel que parcels indique ce que signifie le lien depuis l’expédition. Représente cette référence soit par une association, soit par - parcels: List<Parcel> dans la boîte. Montrer les deux sans raison peut donner l’impression qu’un champ correspond à deux éléments d’état différents.

Choisir le sens de la relation tout-partie

La composition utilise un losange plein du côté du tout. Une partie appartient à au plus un tout composite à la fois et est normalement supprimée avec ce tout, comme une commande et ses lignes de commande. L’agrégation utilise un losange creux pour un regroupement plus souple dont les parties peuvent exister indépendamment. Une équipe peut regrouper des joueurs sans que leur durée de vie dépende d’elle.

Java n’a pas de mot-clé pour le losange et n’impose pas la propriété au sens d’UML simplement parce qu’une liste existe. Modélise une composition uniquement lorsque la conception inclut cette règle de propriété. Lorsque la conception indique simplement qu’un objet en connaît un autre, une association simple est plus claire qu’un losange sans fondement.

Montrer une utilisation sans affirmer une propriété

Une dépendance est un trait en pointillés terminé par une flèche ouverte vers le type utilisé. Un calculateur doté de feeInCents(Parcel parcel) dépend de Parcel, car la signature de sa méthode utilise ce type. Une dépendance est une relation générale d’utilisation ; elle ne se limite pas au code sans champs. Une association fournit une information structurelle plus précise lorsqu’un champ est important pour le modèle.

Avant de tracer un trait, demande-toi ce que le code ou l’exigence établit : une référence, un nombre autorisé, une utilisation ou une propriété. Une collection établit un stockage pouvant contenir plusieurs objets, mais elle n’établit pas à elle seule une propriété exclusive ou un nombre minimal.

L’héritage et l’implémentation d’une interface relient tous deux un type spécifique à un type plus général. UML utilise un triangle creux du côté du type général, mais le style du trait distingue les deux relations. Cette distinction indique quelle déclaration Java écrire.

Lire le triangle et son trait

Un trait plein terminé par un triangle creux du côté de Item signifie qu’une sous-classe comme Letter étend Item. C’est une généralisation. Un trait en pointillés terminé par un triangle creux du côté de ParcelRepository signifie qu’une classe comme InMemoryParcelRepository implémente cette interface. C’est une réalisation.

Le triangle touche toujours la superclasse ou l’interface. Une flèche ouverte en pointillés, sans triangle, indique une dépendance. Le style du trait et la pointe de la flèche portent ensemble la signification ; un trait en pointillés seul ne suffit pas.

Construire le squelette dans un ordre utile

1. Crée chaque classe ou interface dans son paquetage.
2. Traduis les attributs en champs en conservant les noms, les types et la visibilité.
3. Traduis les associations navigables en champs contenant une référence ou une collection.
4. Ajoute extends ou implements à partir des traits de généralisation ou de réalisation.
5. Traduis les opérations en en-têtes de méthodes, puis complète leurs corps.

Supposons qu’une interface propose save et findAll. Une implémentation possède une association vers plusieurs objets Parcel, avec le rôle parcels :

public class InMemoryParcelRepository implements ParcelRepository {
    private List<Parcel> parcels = new ArrayList<>();

    @Override
    public void save(Parcel parcel) {
        parcels.add(parcel);
    }

    @Override
    public List<Parcel> findAll() {
        return new ArrayList<>(parcels);
    }
}

Le trait en pointillés terminé par un triangle donne implements ParcelRepository. L’association donne le champ contenant la liste. Les signatures des opérations donnent les deux méthodes publiques. Les corps des méthodes relèvent d’un choix d’implémentation : ici, save ajoute un objet et findAll renvoie une nouvelle liste pour que le code appelant ne puisse pas ajouter ou supprimer directement des éléments dans la liste stockée. Les objets colis eux-mêmes restent partagés.

Dessiner dans l’autre sens

Commence par une boîte pour chaque classe ou interface. Un champ contenant une valeur simple devient un attribut. Une référence à une classe du programme devient une association ; une collection suggère une extrémité pouvant comporter plusieurs objets. Examine les vérifications des constructeurs et des méthodes avant d’affirmer que la borne inférieure est de un. Traduis extends par un trait plein terminé par un triangle et implements par un trait en pointillés terminé par un triangle.

Les champs et les opérations hérités restent généralement dans la boîte de la superclasse. Place les membres nouveaux ou redéfinis dans la sous-classe. Ajoute une dépendance pour un paramètre, un type de retour ou une utilisation locale lorsque cette relation aide à expliquer la conception.

Les paquetages peuvent entourer leurs classes dans des boîtes en forme de dossier avec un petit onglet. Ces groupes aident à voir quelles parties dépendent des autres. Tiens à jour un diagramme de documentation lorsque le code change ; indique qu’une esquisse de planification est préliminaire pour que les lecteurs comprennent son objectif.

Un Shipment qui contient des colis n’est pas une sorte de Parcel. Sa liste donne une relation « possède » : dessine donc une association. Utilise l’héritage pour une relation « est une sorte de » que le système de types et le comportement Java prennent réellement en charge.

L’interface utilisateur lit les commandes et affiche les résultats. La logique applicative contient les règles et les données sur lesquelles portent ces commandes. Leur séparation permet à un test d’appeler directement un calcul et à une autre interface de le réutiliser sans copier la règle.

Donner une tâche précise à chaque partie

TextUI prend en charge le dialogue : demander un poids, lire une ligne avec Scanner, convertir le texte en nombre, appeler la logique et afficher le résultat. ShippingCalculator accepte un poids en grammes et renvoie des frais en centimes. Il ne pose aucune question à l’utilisateur et n’affiche aucune réponse.

Une méthode appelée printFee mélange ces tâches si elle calcule et affiche à la fois. Remplace l’opération de logique par feeInCents(int weightGrams). L’interface peut alors afficher "Fee: " + calculator.feeInCents(weightGrams) + " cents". Un test peut vérifier par une assertion l’entier renvoyé sans capturer la sortie de la console.

Écrire la règle avec une valeur de retour

La règle d’expédition prévoit des frais de 500 centimes pour les poids positifs jusqu’à 2 000 g inclus, de 900 centimes jusqu’à 10 000 g inclus, puis de 100 centimes supplémentaires par tranche de 1 000 g entamée au-dessus de 10 000 g.

public int feeInCents(int weightGrams) {
    if (weightGrams <= 0) {
        throw new IllegalArgumentException("weight must be positive");
    }
    if (weightGrams <= 2000) {
        return 500;
    }
    if (weightGrams <= 10000) {
        return 900;
    }
    long excess = (long) weightGrams - 10000;
    long startedBlocks = (excess + 999) / 1000;
    return (int) (900 + 100 * startedBlocks);
}

Les deux premières branches qui renvoient un résultat incluent leurs bornes supérieures. Pour 12 500 g, l’excédent est de 2 500 g. La division entière après l’ajout de 999 compte trois tranches entamées, ce qui donne 1 200 centimes. Les calculs intermédiaires en long permettent aussi de traiter de grands poids positifs de type int sans dépassement de capacité lors de l’ajout de 999.

Un poids invalide provoque une IllegalArgumentException : la méthode rejette un argument qui ne respecte pas sa règle. L’interface peut intercepter cette exception et choisir un message lisible. La règle appartient à la logique ; la formulation du message appartient à l’interface.

Relier les objets dans main

Transmets le lecteur d’entrée et le calculateur au constructeur de l’interface :

public static void main(String[] args) {
    Scanner scanner = new Scanner(System.in);
    ShippingCalculator calculator = new ShippingCalculator();
    TextUI ui = new TextUI(scanner, calculator);
    ui.start();
}

Crée un seul scanner pour le flux d’entrée et partage-le avec l’interface. Plusieurs scanners utilisant System.in peuvent interférer avec leurs entrées mises en tampon. La méthode main assemble le programme ; start exécute la boucle de dialogue.

Lorsque tu examines une classe, cherche ses responsabilités. Un Scanner ou System.out dans un calculateur de frais révèle un mélange entre les entrées-sorties et les règles. Une formule de calcul des frais dans l’interface révèle le même problème de l’autre côté. Déplace le calcul dans une méthode avec une entrée explicite et un résultat ; garde l’analyse des commandes et le texte affiché ensemble dans l’interface.

Un programme en couches regroupe les classes selon leur responsabilité. La couche de présentation gère le dialogue, la couche de logique applique les règles et la couche d’accès aux données enregistre et récupère les informations. Une classe utilise une autre couche par une opération clairement définie au lieu d’accéder à ses champs internes.

Placer les classes du programme de colis

Le paquetage de l’interface utilisateur contient TextUI. Celui du domaine contient Parcel, ShippingCalculator et ParcelService. Celui des données contient ParcelRepository et ses implémentations de stockage. Main assemble les objets au-dessus de ces couches.

Une commande suit ce parcours : l’utilisateur saisit « add 1200 Alex » ; l’interface analyse la ligne et appelle service.register(1200, "Alex") ; le service valide le poids, crée un colis, l’enregistre par l’intermédiaire du dépôt et renvoie 500 centimes ; l’interface affiche les frais. La lecture du texte, la décision de ce qui est autorisé et le stockage du résultat sont placés séparément.

Dépendre d’un contrat

Le service a besoin d’un comportement de stockage, pas d’un format de fichier particulier. Exprime ce comportement par une interface :

public interface ParcelRepository {
    void save(Parcel parcel);
    List<Parcel> findAll();
}

Le service stocke une référence de type ParcelRepository et la reçoit dans son constructeur :

public class ParcelService {
    private final ParcelRepository repository;

    public ParcelService(ParcelRepository repository) {
        this.repository = repository;
    }
}

C’est une injection par constructeur, une forme d’injection de dépendances : le code appelant fournit un collaborateur. Un service qui construit new FileParcelRepository(...) dans ses propres méthodes choisit lui-même le stockage dans des fichiers et rend les tests isolés plus difficiles.

Changer l’implémentation lors de l’assemblage

Le programme exécuté peut créer new ParcelService(new FileParcelRepository("parcels.csv")). Un test peut fournir new InMemoryParcelRepository(). Les deux implémentations respectent la même interface. Les appels par l’intermédiaire de l’interface utilisent le polymorphisme pour atteindre les méthodes de l’objet effectif.

Si le contrat du dépôt reste inchangé, changer de stockage nécessite une nouvelle implémentation et une modification lors de l’assemblage. Les règles de calcul des frais et le code du dialogue n’ont pas besoin de connaître la façon dont les données sont stockées.

Vérifier précisément la direction des dépendances

Le parcours descendant d’utilisation des services va de l’interface utilisateur à la logique, puis au stockage. Le domaine ne doit ni importer ni appeler les classes de l’interface utilisateur. Si la logique doit communiquer un résultat à l’utilisateur, renvoie-le à l’interface. Si l’interface enregistre directement par l’intermédiaire du dépôt, elle peut contourner la validation du service.

Les références aux types Java comptent aussi : une signature du dépôt qui nomme Parcel dépend de ce type du domaine. Si ParcelRepository se trouve dans le paquetage des données et le service dans celui du domaine, ces paquetages font référence l’un à l’autre. Pour supprimer ce cycle entre paquetages, place l’interface du dépôt à côté des types du domaine et laisse les implémentations des données l’importer. Le service utilise toujours le même contrat ; seul l’emplacement de celui-ci change. Examine à la fois le parcours des appels de méthodes et les importations lorsque tu vérifies la conception.

Les programmes plus conséquents peuvent d’abord regrouper les paquetages par fonctionnalité, comme les commandes ou les clients, puis séparer les responsabilités au sein de chaque fonctionnalité. Les noms de paquetages aident les lecteurs à localiser les responsabilités ; les paramètres des constructeurs et les signatures des méthodes montrent les dépendances effectives.

Un test unitaire appelle une petite unité de code avec une entrée choisie et vérifie automatiquement le résultat. Il rend une exigence exécutable. Relancer les tests après une modification aide à trouver une régression, c’est-à-dire un bogue dans un comportement qui fonctionnait auparavant.

Créer un test Jupiter

JUnit Jupiter est le modèle de programmation utilisé par JUnit 5 et 6. JUnit 6 nécessite Java 17 ou une version ultérieure. Les annotations et les assertions de test utilisent org.junit.jupiter.api.

Place ShippingCalculatorTest.java sous src/test/java/com/example/parcels/domain, avec la même déclaration de paquetage que le calculateur. La racine des sources distincte sépare les tests du code du programme livré tout en conservant l’accès au même paquetage.

package com.example.parcels.domain;

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

class ShippingCalculatorTest {
    @Test
    void lightParcelCostsBaseFee() {
        ShippingCalculator calculator = new ShippingCalculator();

        int fee = calculator.feeInCents(1500);

        assertEquals(500, fee);
    }
}

La classe et la méthode de test peuvent avoir un accès de paquetage. Une méthode de test renvoie void et ne doit pas être privée. Utilise @Test de Jupiter ; org.junit.Test de JUnit 4 appartient à un autre modèle de programmation et n’est pas découvert par le moteur Jupiter. Les assertions JUnit 4 peuvent fonctionner lorsque leur bibliothèque est disponible, mais utiliser systématiquement les importations Jupiter rend la configuration plus claire.

Lire les étapes préparer–agir–vérifier

La première partie prépare un calculateur. La deuxième agit en demandant les frais. L’assertion finale compare les 500 centimes attendus à la valeur renvoyée. Les lignes vides permettent de repérer facilement ces tâches. Afficher fee seul laisserait à une personne le soin de décider si la valeur est correcte ; l’assertion intègre cette décision au test.

assertEquals(expected, actual) place l’exigence en premier et le résultat observé en second. Un message facultatif vient en dernier, comme dans assertEquals(500, fee, "fee for 1,500 g"). Inverser les deux premiers arguments ne change généralement pas la réussite ou l’échec pour ces valeurs, mais inverse le sens du rapport d’échec.

Choisir l’assertion adaptée

Utilise assertTrue ou assertFalse pour un booléen, et assertNull ou assertNotNull lorsque le résultat porte sur la présence d’un objet. Les vérifications d’égalité des objets utilisent equals ; sans redéfinition, deux objets distincts dont les champs correspondent peuvent malgré tout être considérés comme différents.

Les résultats en virgule flottante nécessitent une tolérance adaptée. Le calcul 0.1 + 0.2 produit 0.30000000000000004 dans un double Java :

assertEquals(0.3, 0.1 + 0.2, 1e-9);

Le troisième argument autorise une différence absolue allant jusqu’à 0.000000001. Choisis une tolérance adaptée au calcul ; une tolérance trop grande peut masquer une erreur qui a un sens. Les calculs en centimes entiers ne nécessitent aucune tolérance décimale.

Lire un échec

Exécute un test depuis l’environnement de développement ou l’outil de construction. Un rapport tel que « expected: <500> but was: <900> » indique les résultats attendu et observé ; la trace de pile pointe vers l’assertion. Une exception inattendue fait aussi échouer un test. Le vert signifie que les cas vérifiés ont réussi ; leur choix reste une partie distincte du travail de test.

Un ensemble de tests utile vérifie la façon dont la spécification répartit les entrées en cas. Une entrée ordinaire teste rarement toute une règle. Les cas limites, à une limite et juste à côté, sont particulièrement efficaces pour détecter une condition écrite avec le mauvais opérateur de comparaison.

Répartir les entrées en classes

Une classe d’équivalence regroupe les entrées qui doivent être traitées de la même façon. La règle d’expédition comporte des poids invalides à zéro ou en dessous, une tranche à 500 centimes jusqu’à 2 000 g inclus, une tranche à 900 centimes jusqu’à 10 000 g inclus et un calcul par tranches entamées au-delà. Choisis des entrées représentatives des classes, puis examine leurs limites.

Remplacer <= 2000 par < 2000 affecte exactement 2 000 g. Un test à 1 500 g réussit toujours. Au-dessus de 10 000 g, teste à la fois une tranche entière et le premier gramme de la tranche suivante pour vérifier l’arrondi supérieur.

Les valeurs attendues proviennent de l’exigence et d’un calcul à la main. Pour 12 500 g, l’excédent est de 2 500 g, ce qui représente trois tranches entamées : le résultat attendu est donc de 1 200 centimes. Exécuter la méthode et copier sa réponse dans le test copierait aussi tout bogue éventuel.

Tester une entrée rejetée

Un test d’exception fournit à JUnit l’opération à exécuter :

assertThrows(IllegalArgumentException.class,
    () -> calculator.feeInCents(0));

L’expression () -> ... est une expression lambda : un petit morceau de code fourni à JUnit. JUnit l’exécute pendant la vérification. Appeler la méthode avant de la transmettre à l’assertion laisserait l’exception se propager avant que la vérification puisse l’examiner.

assertThrows accepte le type d’exception indiqué ou une sous-classe. L’assertion échoue si l’opération se termine normalement ou lève un type incompatible. Elle renvoie l’exception, ce qui permet de vérifier un message exigé :

IllegalArgumentException error = assertThrows(
    IllegalArgumentException.class,
    () -> calculator.feeInCents(0));
assertEquals("weight must be positive", error.getMessage());

Donner un nom lisible à un scénario

Des noms comme zeroWeightIsRejected et feeIsBaseFeeAtExactly2000Grams identifient le comportement recherché. Un test peut comporter plusieurs assertions lorsqu’elles vérifient le même résultat. Après l’ajout de colis de 1 200 g et 800 g à une expédition, vérifier un nombre de deux et un poids total de 2 000 g décrit ce même scénario. assertAll peut regrouper les vérifications afin que tous les échecs soient signalés.

Vérifie les objets modifiés par leur comportement, par exemple avec parcelCount() et totalWeightGrams(), au lieu d’exposer les champs privés pour les tests. Une refactorisation peut alors modifier les détails du stockage tout en préservant les vérifications. Une couverture complète des lignes signifie que les tests ont exécuté les lignes ; elle peut malgré tout laisser passer une limite erronée ou une entrée invalide non testée.

Chaque test doit préparer tout ce dont il a besoin. Un test qui ne réussit qu’après l’ajout de données par un autre test dépend d’un historique caché. Il devient difficile de faire confiance à de tels tests lorsqu’un exécuteur change l’ordre ou n’exécute qu’une seule méthode.

Créer une nouvelle fixture

Une fixture de test est l’ensemble des objets et des données utilisés par un test. Place la préparation répétée avant chaque test dans @BeforeEach :

class ShipmentTest {
    private Shipment shipment;

    @BeforeEach
    void setUp() {
        shipment = new Shipment();
    }

    @Test
    void newShipmentIsEmpty() {
        assertEquals(0, shipment.parcelCount());
    }

    @Test
    void addingParcelIncreasesCount() {
        shipment.add(new Parcel(1200, "Alex"));
        assertEquals(1, shipment.parcelCount());
    }
}

La préparation s’exécute avant chaque méthode. Le deuxième test ne modifie pas l’expédition utilisée par le premier. Par défaut, Jupiter crée aussi une nouvelle instance de la classe de test pour chaque méthode de test. Les champs statiques mutables restent partagés : une liste statique peut donc toujours transmettre un état entre ces instances.

@AfterEach effectue le nettoyage après chaque test. @BeforeAll et @AfterAll s’exécutent une fois pour la classe et sont statiques dans le cycle de vie par défaut. Des données de référence partagées en lecture seule peuvent convenir à une préparation unique pour la classe ; les objets modifiés doivent généralement être recréés pour chaque test. Les tests doivent fonctionner individuellement sans dépendre de l’ordre du fichier source.

Utiliser un même corps de test pour un tableau

Un test paramétré exécute la même vérification de comportement pour plusieurs lignes :

@ParameterizedTest
@CsvSource({"1, 500", "2000, 500", "2001, 900",
            "10000, 900", "10001, 1000"})
void feeMatchesTable(int grams, int expected) {
    assertEquals(expected,
        new ShippingCalculator().feeInCents(grams));
}

Chaque ligne donne lieu à une invocation distincte avec son propre résultat dans le rapport. @ValueSource(ints = {0, -5}) fournit un entier par invocation pour les tests d’entrées invalides. Les annotations des tests paramétrés proviennent de org.junit.jupiter.params ; CsvSource et ValueSource se trouvent dans son paquetage provider. La dépendance agrégée junit-jupiter inclut le module de tests paramétrés.

@DisplayName ajoute un libellé lisible au rapport. @Disabled indique qu’un test est ignoré et en donne la raison ; une vérification ignorée ne prouve pas que le comportement qu’elle testerait fonctionne.

Contrôler l’environnement

Un test de service peut recevoir un InMemoryParcelRepository, un objet factice fonctionnel qui stocke les colis en mémoire. Cela évite d’utiliser le contenu de vrais fichiers et isole la logique. Transmets à une interface textuelle un Scanner construit à partir d’une chaîne connue lorsque tu testes sa gestion des entrées. Une date fixe ou un Random avec une graine fixe rend de même une entrée extérieure prévisible.

Un test instable change de résultat d’une exécution à l’autre sans modification pertinente du code. Les données mutables partagées, l’heure actuelle, les valeurs aléatoires non contrôlées et les fichiers résiduels sont des causes fréquentes. Donne au test le contrôle de ces entrées. Garde les éléments auxiliaires courts et la préparation lisible ; une fixture qui construit de nombreux objets sans rapport entre eux peut révéler que la classe testée a trop de tâches.

Le développement piloté par les tests (TDD) commence une modification du comportement par un test. Un cycle court rend visible le comportement manquant, l’implémente, puis améliore la structure du code. Une liste de tests conserve les cas qui restent à explorer sans exiger de les écrire tous en même temps.

Prendre un élément de la liste des tests

Pour un programme qui vérifie les années bissextiles du calendrier grégorien, énumère quatre comportements : une année ordinaire non bissextile, une année divisible par quatre, une année séculaire non divisible par 400 et une année séculaire divisible par 400. Ces cas représentent différentes parties de la règle.

Rouge : écris un test et exécute-le. Une méthode manquante peut provoquer une erreur de compilation. Une fois la méthode créée, vérifie que le test échoue pour le comportement que tu souhaites ajouter. Une assertion manquante, un mauvais appel de méthode ou un test non découvert peuvent rendre trompeur un résultat apparemment vert. Un nouveau cas peut aussi être déjà satisfait par le code existant ; examine ce résultat avant de modifier l’implémentation.

Vert : ajoute le code le plus simple qui fait réussir le nouveau test et tous les tests précédents. Refactorisation : améliore la structure sans changer le comportement, en relançant les tests après chaque petite modification. Choisis ensuite le cas suivant.

Laisser les cas développer la règle

La première vérification est assertFalse(LeapYears.isLeapYear(2023)). Créer la méthode avec return false; fait réussir ce cas. C’est une première étape délibérée, pas une règle calendaire terminée.

La vérification suivante, assertTrue(LeapYears.isLeapYear(2024)), échoue. Remplace le contenu de la méthode par return year % 4 == 0;. Les deux cas réussissent maintenant.

Ensuite, assertFalse(LeapYears.isLeapYear(1900)) révèle l’exception des années séculaires. Remplacer l’expression par year % 4 == 0 && year % 100 != 0 fait réussir ces trois tests.

Enfin, assertTrue(LeapYears.isLeapYear(2000)) révèle l’exception à la règle des années séculaires. L’implémentation devient :

public static boolean isLeapYear(int year) {
    return year % 400 == 0
        || (year % 4 == 0 && year % 100 != 0);
}

Exécute les quatre vérifications après la modification. Chaque nouvel échec a indiqué une partie manquante du comportement au lieu de te demander de déboguer une grande implémentation inachevée.

Améliorer la structure pendant que les tests sont au vert

La refactorisation modifie les noms ou l’organisation tout en préservant le comportement. Renommer une méthode, extraire une méthode auxiliaire, supprimer une logique répétée et déplacer une classe vers un paquetage plus adapté sont des refactorisations lorsque le comportement observable reste le même. Modifier les frais appliqués à une limite change le comportement et nécessite un test qui décrit ce changement.

Si un nettoyage fait échouer un test, rétablis le comportement voulu avant d’ajouter une autre fonctionnalité. De petites modifications aident à localiser la cause d’un échec. Sauter le nettoyage laisse du code qui réussit les tests mais devient plus difficile à enrichir ; écrire une grande implémentation pour de nombreux cas futurs crée davantage de code à examiner lorsque la vérification suivante échoue.

Le TDD dépend de la qualité des exigences et des cas choisis. Une règle mal comprise peut apparaître à la fois dans le test et dans l’implémentation. Une logique dont les entrées et les sorties sont claires constitue un bon point de départ, car le résultat attendu peut être indiqué indépendamment et vérifié rapidement.

Un outil de construction transforme des fichiers sources en un résultat vérifié et empaqueté. Maven lit une description du projet, télécharge les bibliothèques déclarées, compile le code, exécute les tests et crée un artefact. La même description donne à la ligne de commande et à l’environnement de développement une vue commune du projet.

Utiliser l’organisation standard

Place le code Java de production dans src/main/java, les tests dans src/test/java, les ressources de production dans src/main/resources et les données de test dans src/test/resources. Les répertoires de paquetages commencent sous chaque racine des sources Java. Maven écrit les résultats générés sous target ; modifie les sources, pas les copies compilées dans ce répertoire.

Le fichier pom.xml à la racine du projet, le Project Object Model, identifie le projet à l’aide de coordonnées : groupId, artifactId et version. Par exemple, com.example:parcels:1.0-SNAPSHOT identifie une version en cours de développement du programme de colis. Une dépendance à une bibliothèque possède aussi des coordonnées.

Déclarer JUnit pour les tests

Voici une petite configuration Maven complète. Elle compile pour Java 17 et sélectionne un exécuteur de tests compatible avec Jupiter :

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>parcels</artifactId>
  <version>1.0-SNAPSHOT</version>
  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>6.1.3</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.14.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.4</version>
      </plugin>
    </plugins>
  </build>
</project>

Maven récupère les dépendances depuis des dépôts, normalement Maven Central, et les met en cache dans .m2/repository sous ton dossier personnel. Les bibliothèques nécessaires à une dépendance sont des dépendances transitives. La portée test rend JUnit disponible pour compiler et exécuter les tests, mais pas pour la compilation du code principal ni dans le chemin de classes du programme à l’exécution. Un JAR ordinaire conserve les JAR de ses dépendances séparément, sauf si l’empaquetage est configuré pour les regrouper.

Demander une phase du cycle de vie

Le cycle de vie principal passe notamment par les phases de compilation, de test, d’empaquetage et d’installation. Demander package exécute aussi les phases précédentes. Avec le wrapper, ./mvnw test compile et teste ; ./mvnw package crée aussi le JAR sous target ; ./mvnw install place en outre l’artefact dans le dépôt local. Le cycle de vie de nettoyage distinct, ./mvnw clean, supprime les résultats générés.

Un échec de test arrête la construction normale avant l’empaquetage d’un nouvel artefact. Un ancien JAR peut encore être présent jusqu’au nettoyage : sa présence ne prouve donc pas que la dernière construction a réussi.

Rendre visible la découverte des tests

Les motifs par défaut de Surefire incluent les noms commençant par Test ou se terminant par Test, Tests ou TestCase. ShippingChecks ne leur correspond pas ; utilise ShippingCalculatorTest et examine le nombre de tests indiqué. Les tests placés sous src/main/java ne peuvent pas utiliser une dépendance de portée test.

Le Maven Wrapper, mvnw ou mvnw.cmd sous Windows, exécute la version de Maven indiquée par le projet. Utilise un projet qui inclut les fichiers de son wrapper ; un POM seul ne crée pas les scripts. Depuis la racine du projet, le wrapper fournit une commande de construction cohérente sans installation séparée de Maven.

Gradle décrit une construction avec un script et exécute des tâches avec leurs dépendances. Un script Kotlin se nomme build.gradle.kts ; un script Groovy se nomme build.gradle. Les plugins fournissent des tâches et les configurations de dépendances indiquent où les bibliothèques sont nécessaires.

Configurer une application et Jupiter

Un fichier settings.gradle.kts à la racine du projet peut contenir rootProject.name = "parcels". Un script de construction Kotlin correspondant est :

plugins {
    application
}

repositories {
    mavenCentral()
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

dependencies {
    testImplementation(platform("org.junit:junit-bom:6.1.3"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

application {
    mainClass = "com.example.parcels.Main"
}

tasks.test {
    useJUnitPlatform()
}

Le plugin application fournit les tâches de construction Java et ajoute run. mavenCentral() sélectionne un dépôt de dépendances. La nomenclature de dépendances, ou BOM, aligne les versions des modules JUnit : la version n’apparaît donc qu’une fois. testImplementation fournit les bibliothèques nécessaires pour compiler et exécuter les tests. testRuntimeOnly fournit le lanceur uniquement pendant leur exécution. Les bibliothèques du code principal utilisent implementation, ce qui les rend aussi disponibles pour le code de test.

useJUnitPlatform() sélectionne la plateforme qui exécute les tests Jupiter. Ajouter les bibliothèques Jupiter sans configurer l’exécuteur peut empêcher la découverte de ces tests. Avec son réglage par défaut, Gradle dans ses versions actuelles échoue lorsque des sources de test existent mais qu’aucun test n’est découvert ; examine la sortie et la configuration de la tâche de test au lieu de supprimer la vérification.

Exécuter des tâches avec le wrapper

Utilise le wrapper fourni avec le projet : ./gradlew test exécute les tests ; ./gradlew build compile, teste et empaquette ; ./gradlew run démarre la classe principale configurée ; et ./gradlew clean supprime build. Sous Windows, utilise gradlew.bat. Gradle utilise la même organisation des sources principales et de test que Maven et écrit les résultats générés dans build.

Une tâche marquée UP-TO-DATE possède des entrées et des sorties suivies qui n’ont pas changé : Gradle réutilise donc son résultat précédent. Ce message se distingue d’une nouvelle exécution des tests. Le rapport de test HTML se trouve dans build/reports/tests/test/index.html.

Trouver l’étape qui a échoué

Commence par la première erreur exploitable. « Cannot find symbol » pendant la compilation principale indique un problème dans le code nommé, une importation ou une dépendance. L’absence de org.junit.jupiter.api pendant la compilation des tests indique un problème de configuration des dépendances de test ; la même erreur pendant la compilation principale peut signifier qu’un test a été placé dans le répertoire des sources principales. Une erreur de résolution de dépendance oriente vers les coordonnées, l’accès au dépôt ou la disponibilité du réseau.

L’échec d’un test en cours d’exécution est différent : le test a été compilé et découvert, mais sa vérification a échoué. Si « expected: <500> but was: <900> » apparaît à la limite de 2 000 g pour les frais, examine la comparaison qui choisit la tranche. Modifier les dépendances ne corrigera pas ce calcul.

Maven propose une description XML déclarative avec des phases de cycle de vie fixes. Gradle propose des scripts et des tâches configurables, notamment la possibilité de sauter le travail déjà à jour. Les deux automatisent des constructions Java reproductibles ; utilise l’outil choisi pour le projet et lis le premier échec sur lequel tu peux agir avant de modifier le code.