Pakete, Klassendiagramme und Modultests in Java

Ein Paket gruppiert zusammengehörige Klassen und Interfaces unter einem Namen. Es trennt außerdem Namen: Zwei Klassen namens Parcel können nebeneinander bestehen, wenn ihre Paketnamen verschieden sind. Ein Paket bietet Java sowohl eine Zugriffsgrenze als auch eine Möglichkeit, Dateien zu ordnen.

Deklariere zuerst das Paket

Eine gewöhnliche Quelldatei beginnt mit ihrer Paketdeklaration, gefolgt von Importdeklarationen und dann der Klasse. Vor der Deklaration dürfen Kommentare stehen. Zum Beispiel:

package com.example.parcels.domain;

public class Parcel {
    private int weightGrams;

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

Jeder Typ auf oberster Ebene in dieser Datei gehört zu com.example.parcels.domain. Eine Datei hat höchstens eine Paketdeklaration. Die öffentliche Klasse Parcel gehört in Parcel.java; allein durch das Ändern des Verzeichnisses ändert sich das deklarierte Paket nicht.

Wandle Punkte in Verzeichnisse um

Das Quellverzeichnis ist das Verzeichnis, in dem der Paketpfad beginnt. In einem standardmäßigen Maven- oder Gradle-Projekt beginnt der Java-Hauptcode bei src/main/java. Ersetze jeden Punkt im Paketnamen durch einen Schrägstrich und füge dann den Klassennamen hinzu:

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

Das Paket heißt com.example.parcels.domain, nicht src.main.java.com.example.parcels.domain. Die ersten drei Verzeichnisse beschreiben die Build-Struktur; sie sind kein Teil des Java-Namens. Meldet eine IDE eine Abweichung beim Paket, vergleiche die Deklaration mit dem Pfad unterhalb des Quellverzeichnisses. Verschiebe die Datei oder korrigiere die Deklaration, sodass beides übereinstimmt.

Paketnamen verwenden Kleinbuchstaben. Organisationen kehren gewöhnlich ihre Domain um: Aus example.com wird com.example, gefolgt vom Projekt und seinem Bereich. Ein Projekt ohne Domain kann parcels.domain verwenden. Enthält ein Teil der umgekehrten Domain einen Bindestrich, ersetze ihn durch einen Unterstrich, wie in org.example.hyphenated_name. Vermeide die Namensräume java und javax der Plattform.

Verwende den vollständigen Klassennamen

Ein vollständig qualifizierter Name verbindet Paketnamen und einfachen Klassennamen: com.example.parcels.domain.Parcel. Er identifiziert die Klasse auch dann, wenn ein anderes Paket ebenfalls eine Klasse Parcel enthält. Im Code kann eine zugängliche Klasse ohne Import vollständig benannt werden:

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

Um eine Hauptklasse in einem Paket zu starten, gib ihren vollständigen Namen und einen Klassenpfad an, der auf die Wurzel des kompilierten Paketbaums zeigt. Vom Projektverzeichnis aus:

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

Hier erzeugt javac -d out den Ausgabebaum, und java -cp out sucht von dessen Wurzel aus. Startest du java Main aus einem Paketverzeichnis, fehlt der Paketanteil der Klassenidentität. Build-Werkzeuge und IDEs verwalten diese Befehle normalerweise.

Unterscheide benachbarte Pakete

com.example.parcels und com.example.parcels.domain sind getrennte Pakete. Ein gemeinsamer Namensanfang verleiht keine zusätzlichen Zugriffsrechte. Eine Datei ohne Deklaration gehört zum unbenannten Paket. Benannte Pakete können dessen Klassen nicht importieren. Verwende daher in einem Programm mit mehreren Teilen durchgehend benannte Pakete.

Ein Import ermöglicht es einer Quelldatei, den einfachen Namen eines zugänglichen Typs zu verwenden. Er teilt dem Compiler mit, was der Name bezeichnet. Er kopiert weder die Klasse, lädt eine Bibliothek herunter noch macht er eine verborgene Klasse öffentlich.

Lies den Anfang einer Quelldatei

Die Benutzeroberfläche gehört zu einem Paket und verwendet Klassen aus zwei anderen:

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 und ShippingCalculator stammen aus dem Domain-Paket des Programms; Scanner stammt aus der Java-Bibliothek. Jeder Import gilt nur für diese Datei. Eine andere Datei, die Scanner verwendet, benötigt einen eigenen Import oder den vollständigen Namen java.util.Scanner.

Wähle einen einzelnen Typ oder einen Wildcard-Import

import java.util.Scanner; ist ein Einzeltypimport. Die genaue Klasse ist für den Leser sichtbar. import java.util.*; ist ein Wildcard-Import: Zugängliche Typen in diesem Paket können bei ihrer Verwendung mit ihrem einfachen Namen bezeichnet werden. Der Wildcard-Import lädt keine unbenutzten Klassen in das Programm und verlangsamt es nicht.

Der Wildcard-Import endet bei diesem Paket. Er umfasst weder java.util.function.Function noch java.util.stream.Collectors, die in getrennten Paketen liegen. Dieselbe Regel gilt für eigenen Code: import com.example.parcels.*; erreicht com.example.parcels.domain.Parcel nicht.

In drei Fällen ist kein Import nötig: bei Typen im selben Paket, automatisch verfügbaren Typen in java.lang und vollständig benannten Typen. Deshalb erscheinen String, System, Math, Integer und Object häufig ohne Importdeklaration.

Löse einen gemeinsamen einfachen Namen auf

Sowohl java.util als auch java.awt enthalten eine Klasse namens List. Zwei Einzeltypimporte für diese verschiedenen Klassen verursachen einen Kompilierfehler. Zwei Wildcard-Importe können nebeneinander bestehen, aber der einfache Name List wird bei seiner Verwendung mehrdeutig. Ein Einzeltypimport hat Vorrang vor einem Wildcard-Import.

Werden beide Klassen benötigt, importiere eine und schreibe die andere aus:

import java.util.List;

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

Java-Importe bieten keine Alias-Syntax wie import ... as .... Mit dem vollständig qualifizierten Namen lässt sich der zweite Typ unterscheiden.

Importiere ein statisches Mitglied

Ein statischer Import macht den Namen der zugehörigen Klasse beim Aufruf eines statischen Mitglieds überflüssig:

import static java.lang.Math.sqrt;

Die Datei kann nun sqrt(16.0) aufrufen. Testcode verwendet häufig import static org.junit.jupiter.api.Assertions.assertEquals;, sodass Assertions als direkte Prüfungen lesbar sind. Setze statische Importe in gewöhnlichem Programmcode gezielt ein, damit Leser weiterhin erkennen können, woher Operationen stammen.

Beachte die Fehlermeldung

„Cannot find symbol“ kann einen fehlenden Import oder einen falsch geschriebenen Typ bedeuten. „Package ... does not exist“ deutet auf ein Problem mit der Schreibweise des Pakets, dem Quellverzeichnis oder einer Abhängigkeit hin. „Is not public ... cannot be accessed from outside package“ bedeutet, dass Java den Typ gefunden hat, der Zugriff aber gesperrt ist. Ein weiterer Import kann diesen Zugriffsfehler nicht beheben; prüfe die Klassendeklaration und die benötigten Mitglieder.

Ein Paket sollte die Klassen und Methoden zugänglich machen, die andere Teile benötigen, und Implementierungsdetails verborgen halten. Zugriffsmodifikatoren setzen diese Grenze durch. Ein Import kann einen Namen verkürzen, aber keine Grenze überschreiten, die Java-Zugriffsregeln schließen.

Wähle den Zugriff für ein Klassenmitglied

Kein Modifikator bedeutet für gewöhnliche Klassenmitglieder und Konstruktoren package-private, also Paketzugriff. Es gibt kein entsprechendes Schlüsselwort default. Eine Klasse auf oberster Ebene hat nur zwei Möglichkeiten: public oder package-private. Eine öffentliche Klasse auf oberster Ebene wird in einer Datei mit ihrem Namen gespeichert, etwa ShippingCalculator.java.

Prüfe den Typ und die Operation

Angenommen, die Benutzeroberfläche muss ein Paket erzeugen. Eine öffentliche Klasse allein reicht nicht aus:

package com.example.parcels.domain;

public class Parcel {
    private int weightGrams;

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

Der Konstruktor hat Paketzugriff. Code in com.example.parcels.ui kann Parcel benennen, aber nicht new Parcel(1200) aufrufen. Mache den Konstruktor public, wenn das Erzeugen von Paketen zum öffentlichen Angebot des Pakets gehört. Halte weightGrams privat und stelle stattdessen eine passende Operation bereit, statt das Feld freizugeben.

Beim Paketzugriff wird der gesamte Paketname verglichen. Weder ein übergeordnet aussehendes noch ein untergeordnet aussehendes Paket ist dasselbe Paket. Code in com.example.parcels erhält keinen besonderen Zugriff auf Hilfsklassen in com.example.parcels.domain.

Verstehe geschützten Zugriff

protected erlaubt den Zugriff sowohl aus nicht verwandten Klassen im deklarierenden Paket als auch aus Unterklassen. Über Paketgrenzen hinweg erfolgt der Zugriff auf ein Instanzmitglied im Vererbungskontext der Unterklasse. Eine Unterklasse kann ihr eigenes geerbtes Feld verwenden, aber kein beliebiges Oberklassenobjekt nutzen, um die Paketgrenze zu umgehen.

Wenn zum Beispiel Item das Feld protected int weightGrams deklariert, kann ein Letter extends Item in einem anderen Paket this.weightGrams verwenden. Innerhalb von Letter erlaubt ein Parameter, der lediglich als Item typisiert ist, keinen Zugriff über item.weightGrams; eine als Letter typisierte Referenz erlaubt den geerbten Zugriff dagegen. Diese Einschränkung verhindert, dass die Rechte einer Unterklasse zu einem allgemeinen Zugriff auf jedes Item werden.

Verberge Hilfsklassen bewusst

Mache ShippingCalculator und feeInCents öffentlich, wenn die Benutzeroberfläche sie aufruft. Eine unterstützende Klasse WeightBands kann Paketzugriff behalten. Code außerhalb des Domain-Pakets hängt dann vom Verhalten des Rechners ab und nicht davon, wie er die Tabelle speichert. Wird diese Hilfsklasse ersetzt, sind an anderer Stelle weniger Änderungen nötig.

Tests können denselben Paketnamen wie die getestete Klasse verwenden und dennoch unter src/test/java liegen. Dadurch erhalten sie Paketzugriff, ohne Testcode zwischen den Programmdateien abzulegen. Zugriff auf private Felder erhalten sie dadurch nicht. Jedes Mitglied nur für einen Test öffentlich zu machen, verbreitet Abhängigkeiten von Interna; teste stattdessen öffentliches Verhalten oder eine nützliche Operation mit Paketzugriff.

Ein UML-Klassendiagramm zeigt die statische Struktur: Klassen, ihre Mitglieder und Beziehungen. Es hilft zu erkennen, welche Arten von Objekten es gibt und was sie anbieten. Es verfolgt nicht die Reihenfolge der Methodenaufrufe während der Ausführung.

Lies die drei Bereiche

Ein Klassenkasten enthält oben den Klassennamen, in der Mitte Attribute und unten Operationen. Ein Attribut stellt gewöhnlich ein Java-Feld dar; eine Operation stellt die sichtbare Signatur einer Methode dar. Eine Skizze kann Bereiche weglassen, die ihrem Zweck nicht dienen.

Für ein Paket sieht eine textuelle Darstellung des Kastens so aus:

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

Der Konstruktor trägt den Namen der Klasse und hat keinen Rückgabetyp. Die Methode isHeavierThan nimmt eine Ganzzahl namens limitGrams entgegen und gibt einen booleschen Wert zurück.

Übertrage die Reihenfolge von Namen und Typen

UML setzt den Namen vor den Typ: weightGrams: int. Java setzt den Typ an die erste Stelle: int weightGrams. Bei einer Operation stehen auch die Parameternamen vor den Typen; der Rückgabetyp folgt nach der schließenden Klammer.

private int weightGrams;

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

Dieser Code entspricht - weightGrams: int und + isHeavierThan(limitGrams: int): boolean. Ein Methodenrumpf fehlt gewöhnlich im Diagramm; die Operation gibt an, was aufgerufen werden kann, nicht den Algorithmus.

Beachte Sichtbarkeit und besondere Kennzeichnungen

Die Sichtbarkeitssymbole sind + für public, - für private, # für protected und ~ für Paketzugriff. Setze das Symbol vor den Mitgliedsnamen. Fehlt in einem vorgegebenen Diagramm ein Symbol, erfinde die Sichtbarkeit nicht; ergänze bei der Dokumentation von Code das vorgesehene Symbol.

Ein statisches Mitglied wird unterstrichen. Es gehört zur Klasse und nicht zu jedem einzelnen Objekt. Eine abstrakte Klasse oder Operation wird kursiv geschrieben oder mit {abstract} markiert, wenn Kursivschrift unpraktisch ist. Die Markierung als abstrakt bedeutet, dass eine Unterklasse fehlendes Verhalten bereitstellen muss, bevor ein Objekt aus einer konkreten Klasse erzeugt werden kann.

Ein Interface-Kasten trägt «interface» über seinem Namen. Beispielsweise kann ParcelRepository + save(parcel: Parcel): void und + findAll(): List<Parcel> anbieten. Der Kasten beschreibt einen Vertrag; er legt keine Speicherimplementierung fest.

Wähle den benötigten Detailgrad

Eine Planungsskizze zeigt vielleicht nur Parcel, Shipment und deren wichtigste Operationen. Ein Diagramm zur Implementierung einer Klasse benötigt Typen und Sichtbarkeit. Werden alle gewöhnlichen Getter aufgeführt, können die Beziehungen verdeckt werden, die das Diagramm zeigen sollte. Wähle nützliche Mitglieder und halte sie mit dem Code konsistent: Ein privates Java-Feld sollte nicht mit einem öffentlichen + erscheinen, und eine statische Methode benötigt ihre Unterstreichung.

Eine Assoziation zeigt eine strukturelle Verbindung zwischen Objekten. In Java hält ein Objekt häufig eine Referenz auf ein anderes in einem Feld. Die Linie kann auch zeigen, wie viele Objekte zulässig sind und in welcher Richtung der Referenz gefolgt werden kann.

Zähle vom gegenüberliegenden Ende aus

Die Multiplizität steht neben der Klasse, deren Objekte sie zählt. Steht 1..* neben Parcel und 1 neben Shipment, hat eine Sendung ein oder mehrere Pakete, und jedes Paket gehört zu genau einer Sendung. Lies jedes Ende einzeln, ausgehend von einem Objekt am gegenüberliegenden Ende.

Eine einzelne Referenz kann 1 oder 0..1 darstellen; eine Collection stellt ein mehrwertiges Ende dar. Eine Java-List allein erzwingt keine Untergrenze. Eine Shipment mit der Paketregel 1..* muss eine anfangs leere Liste zurückweisen und verhindern, dass spätere Operationen sie leer zurücklassen. Ebenso benötigt eine vorgeschriebene einzelne Referenz eine Prüfung auf null.

Folge der Referenz

Eine offene Pfeilspitze bei Parcel bedeutet, dass einer Referenz von Shipment zu Parcel gefolgt werden kann. Ein Klassendiagramm kann die Navigierbarkeit offenlassen. In der hier verwendeten Lehrkonvention kennzeichnen Pfeile einseitige Referenzen; eine Linie ohne Pfeil kann beidseitigen Zugriff oder eine nicht festgelegte Richtung bedeuten. Schließe aus einem Pfeil zu Parcel allein nicht auf ein Feld für die Rückreferenz.

Ein Rollenname wie parcels bezeichnet, was die Verbindung aus Sicht der Sendung bedeutet. Zeige diese Referenz entweder als Assoziation oder als - parcels: List<Parcel> im Kasten. Werden ohne Grund beide Formen dargestellt, kann ein Feld wie zwei verschiedene Bestandteile des Zustands aussehen.

Wähle die Bedeutung der Ganzes-Teil-Beziehung

Eine Komposition verwendet eine ausgefüllte Raute am Ganzen. Ein Teil gehört zu einem Zeitpunkt höchstens zu einem zusammengesetzten Ganzen und wird normalerweise mit diesem entfernt, wie eine Bestellung und ihre Bestellpositionen. Eine Aggregation verwendet eine nicht ausgefüllte Raute für eine lockerere Gruppierung, deren Teile unabhängig existieren können. Ein Team kann Spieler gruppieren, ohne deren Lebensdauer zu bestimmen.

Java hat kein Schlüsselwort für die Raute und erzwingt UML-Besitzverhältnisse nicht allein deshalb, weil eine Liste existiert. Modelliere eine Komposition nur, wenn der Entwurf diese Besitzregel enthält. Besagt der Entwurf lediglich, dass ein Objekt ein anderes kennt, ist eine einfache Assoziation klarer als eine unbegründete Raute.

Zeige eine Verwendung, ohne Besitz zu behaupten

Eine Abhängigkeit ist eine gestrichelte Linie mit einer offenen Pfeilspitze zum verwendeten Typ. Ein Rechner mit feeInCents(Parcel parcel) hängt von Parcel ab, weil seine Methodensignatur diesen Typ verwendet. Eine Abhängigkeit ist eine allgemeine Verwendungsbeziehung; sie ist nicht auf Code ohne Felder beschränkt. Eine Assoziation liefert genauere Strukturinformationen, wenn ein Feld für das Modell wichtig ist.

Frag dich vor dem Zeichnen einer Linie, was der Code oder die Anforderung festlegt: eine Referenz, eine zulässige Anzahl, eine Verwendung oder Besitz. Eine Collection legt eine mehrwertige Speicherung fest, aber für sich genommen weder ausschließlichen Besitz noch eine Mindestanzahl.

Sowohl Vererbung als auch Interface-Implementierung verbinden einen spezielleren Typ mit einem allgemeineren. UML verwendet am allgemeinen Typ ein nicht ausgefülltes Dreieck, unterscheidet die beiden Beziehungen aber durch den Linienstil. Dieser Unterschied zeigt dir, welche Java-Deklaration du schreiben musst.

Lies das Dreieck und seine Linie

Eine durchgezogene Linie mit einem nicht ausgefüllten Dreieck an Item bedeutet, dass eine Unterklasse wie Letter Item erweitert. Das ist Generalisierung. Eine gestrichelte Linie mit einem nicht ausgefüllten Dreieck an ParcelRepository bedeutet, dass eine Klasse wie InMemoryParcelRepository dieses Interface implementiert. Das ist Realisierung.

Das Dreieck berührt immer die Oberklasse oder das Interface. Ein gestrichelter offener Pfeil ohne Dreieck bedeutet dagegen eine Abhängigkeit. Linienstil und Pfeilspitze ergeben zusammen die Bedeutung; eine gestrichelte Linie allein reicht nicht aus.

Baue das Grundgerüst in einer sinnvollen Reihenfolge

1. Erstelle jede Klasse und jedes Interface im jeweiligen Paket.
2. Übertrage Attribute in Felder und behalte Namen, Typen und Sichtbarkeit bei.
3. Übertrage navigierbare Assoziationen in Referenz- oder Collection-Felder.
4. Ergänze extends oder implements anhand der Generalisierungs- oder Realisierungslinien.
5. Übertrage Operationen in Methodenköpfe und ergänze anschließend ihre Rümpfe.

Angenommen, ein Interface bietet save und findAll an. Eine Implementierung hat eine mehrwertige Assoziation zu Parcel mit der Rolle 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);
    }
}

Die gestrichelte Linie mit Dreieck liefert implements ParcelRepository. Die Assoziation liefert das Listenfeld. Die Operationssignaturen liefern die beiden öffentlichen Methoden. Die Methodenrümpfe sind eine Implementierungsentscheidung: Hier hängt save ein Objekt an, und findAll gibt eine neue Liste zurück, sodass aufrufender Code keine Einträge direkt in der gespeicherten Liste hinzufügen oder entfernen kann. Die Paketobjekte selbst werden weiterhin gemeinsam genutzt.

Zeichne in die andere Richtung

Beginne mit einem Kasten für jede Klasse und jedes Interface. Ein Feld mit einem einfachen Wert wird zu einem Attribut. Eine Referenz auf eine Klasse im Programm wird zu einer Assoziation; eine Collection legt ein mehrwertiges Ende nahe. Prüfe die Kontrollen in Konstruktoren und Methoden, bevor du eine Untergrenze von eins angibst. Übertrage extends in eine durchgezogene Linie mit Dreieck und implements in eine gestrichelte Linie mit Dreieck.

Geerbte Felder und Operationen bleiben gewöhnlich im Kasten der Oberklasse. Setze neue oder überschriebene Mitglieder in die Unterklasse. Ergänze eine Abhängigkeit für einen Parameter, Rückgabetyp oder eine lokale Verwendung, wenn diese Beziehung den Entwurf erklärt.

Pakete können ihre Klassen in ordnerförmigen Kästen mit einem kleinen Reiter umgeben. Diese Gruppen helfen zu erkennen, welche Bereiche von welchen anderen abhängen. Halte ein Dokumentationsdiagramm bei Codeänderungen aktuell; kennzeichne eine frühe Planungsskizze, damit Leser ihren Zweck verstehen.

Eine Shipment, die Pakete enthält, ist keine Art von Parcel. Ihre Liste beschreibt eine „Hat-ein“-Beziehung, zeichne also eine Assoziation. Verwende Vererbung für eine „Ist-eine-Art-von“-Beziehung, die das Java-Typsystem und das Verhalten tatsächlich unterstützen.

Die Benutzeroberfläche liest Befehle und zeigt Ergebnisse an. Die Anwendungslogik enthält die Regeln und Daten, auf die diese Befehle wirken. Durch die Trennung kann ein Test eine Berechnung direkt aufrufen, und eine andere Oberfläche kann sie wiederverwenden, ohne die Regel zu kopieren.

Gib jedem Teil eine klare Aufgabe

TextUI übernimmt den Dialog: nach einem Gewicht fragen, mit Scanner eine Zeile lesen, den Text in eine Zahl umwandeln, die Logik aufrufen und das Ergebnis ausgeben. ShippingCalculator nimmt ein Gewicht in Gramm entgegen und gibt eine Gebühr in Cent zurück. Die Klasse fragt den Benutzer nichts und gibt keine Antwort aus.

Eine Methode namens printFee vermischt diese Aufgaben, wenn sie sowohl berechnet als auch ausgibt. Ändere die Logikoperation zu feeInCents(int weightGrams). Die Benutzeroberfläche kann dann "Fee: " + calculator.feeInCents(weightGrams) + " cents" ausgeben. Ein Test kann den zurückgegebenen Ganzzahlwert mit einer Assertion prüfen, ohne die Konsolenausgabe abzufangen.

Formuliere die Regel als Rückgabewert

Die Paketregel berechnet 500 Cent für positive Gewichte bis einschließlich 2.000 g, 900 Cent bis einschließlich 10.000 g und danach zusätzliche 100 Cent für je angefangene 1.000 g über 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);
}

Die ersten beiden erfolgreichen Zweige schließen ihre Obergrenzen ein. Bei 12.500 g beträgt der Überschuss 2.500 g. Die Ganzzahldivision nach der Addition von 999 zählt drei angefangene Blöcke, sodass 1.200 Cent entstehen. Die Zwischenrechnung mit long verarbeitet auch große positive int-Gewichte, ohne beim Addieren von 999 überzulaufen.

Ein ungültiges Gewicht löst eine IllegalArgumentException aus: Die Methode weist ein Argument zurück, das gegen ihre Regel verstößt. Die Benutzeroberfläche kann diese Ausnahme abfangen und eine verständliche Meldung wählen. Die Regel gehört zur Logik; die Formulierung der Meldung gehört zur Oberfläche.

Verbinde die Objekte in main

Übergib den Eingabeleser und den Rechner an den Konstruktor der Benutzeroberfläche:

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

Erzeuge einen Scanner für den Eingabestrom und verwende ihn gemeinsam mit der Benutzeroberfläche. Mehrere Scanner für System.in können sich bei der gepufferten Eingabe gegenseitig stören. Die main-Methode setzt das Programm zusammen; start führt die Dialogschleife aus.

Achte beim Prüfen einer Klasse auf ihre Verantwortlichkeiten. Ein Scanner oder System.out innerhalb eines Gebührenrechners zeigt, dass Ein- und Ausgabe mit Regeln vermischt werden. Eine Gebührenformel in der Benutzeroberfläche zeigt dasselbe Problem von der anderen Seite. Verschiebe die Berechnung in eine Methode mit ausdrücklicher Eingabe und einem Ergebnis; halte das Parsen von Befehlen und die Anzeigetexte gemeinsam in der Benutzeroberfläche.

Ein Programm mit Schichten gruppiert Klassen nach Verantwortung. Die Präsentationsschicht übernimmt den Dialog, die Logikschicht wendet Regeln an und die Datenzugriffsschicht speichert Informationen und ruft sie ab. Eine Klasse verwendet eine andere Schicht über eine klar definierte Operation, statt auf deren interne Felder zuzugreifen.

Ordne die Paketklassen zu

Das UI-Paket enthält TextUI. Das Domain-Paket enthält Parcel, ShippingCalculator und ParcelService. Das Datenpaket enthält ParcelRepository und dessen Speicherimplementierungen. Main setzt die Objekte oberhalb dieser Schichten zusammen.

Ein Befehl nimmt diesen Weg: Der Benutzer gibt „add 1200 Alex“ ein; die Benutzeroberfläche parst ihn und ruft service.register(1200, "Alex") auf; der Service validiert das Gewicht, erzeugt ein Paket, speichert es über das Repository und gibt 500 Cent zurück; die Benutzeroberfläche gibt die Gebühr aus. Das Lesen von Text, die Entscheidung darüber, was erlaubt ist, und das Speichern des Ergebnisses haben getrennte Zuständigkeiten.

Hänge von einem Vertrag ab

Der Service benötigt Speicherverhalten, kein bestimmtes Dateiformat. Drücke dieses Verhalten durch ein Interface aus:

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

Der Service speichert eine als ParcelRepository typisierte Referenz und erhält sie im Konstruktor:

public class ParcelService {
    private final ParcelRepository repository;

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

Das ist Konstruktorinjektion, eine Form der Abhängigkeitsinjektion: Der aufrufende Code stellt ein benötigtes Partnerobjekt bereit. Ein Service, der innerhalb seiner eigenen Methoden new FileParcelRepository(...) erzeugt, entscheidet sich selbst für Dateispeicherung und erschwert isolierte Tests.

Ändere die Implementierung beim Zusammensetzen

Das laufende Programm kann new ParcelService(new FileParcelRepository("parcels.csv")) erzeugen. Ein Test kann new InMemoryParcelRepository() bereitstellen. Beide Implementierungen erfüllen dasselbe Interface. Aufrufe über das Interface erreichen durch Polymorphie die Methoden des tatsächlichen Objekts.

Bleibt der Repository-Vertrag unverändert, erfordert ein Wechsel der Speicherung eine neue Implementierung und eine Änderung beim Zusammensetzen. Gebührenregeln und Dialogcode müssen nicht wissen, wie die Daten gespeichert werden.

Prüfe die Richtung der Abhängigkeiten genau

Der nach unten gerichtete Pfad der Dienstnutzung verläuft von der Benutzeroberfläche über die Logik zur Speicherung. Das Domain-Paket darf keine UI-Klassen importieren oder aufrufen. Muss die Logik dem Benutzer ein Ergebnis mitteilen, gib es an die Benutzeroberfläche zurück. Speichert die Benutzeroberfläche direkt über das Repository, kann sie die Validierung des Service umgehen.

Auch Java-Typreferenzen sind wichtig: Eine Repository-Signatur, die Parcel nennt, hängt von diesem Domain-Typ ab. Liegt ParcelRepository im Datenpaket und der Service im Domain-Paket, verweisen diese Pakete aufeinander. Um diese zyklische Paketabhängigkeit zu beseitigen, platziere das Repository-Interface neben den Domain-Typen und lass es von den Datenimplementierungen importieren. Der Service verwendet weiterhin denselben Vertrag; nur dessen Ablageort ändert sich. Prüfe beim Beurteilen des Entwurfs sowohl den Pfad der Methodenaufrufe als auch die Importe.

Größere Programme können Pakete zunächst nach Funktionalität gruppieren, etwa nach Bestellungen oder Kunden, und dann innerhalb jedes Bereichs die Verantwortlichkeiten trennen. Paketnamen helfen Lesern, Verantwortlichkeiten zu finden; Konstruktorparameter und Methodensignaturen zeigen die tatsächlichen Abhängigkeiten.

Ein Modultest ruft eine kleine Codeeinheit mit ausgewählter Eingabe auf und prüft das Ergebnis automatisch. Er macht eine Anforderung ausführbar. Tests nach einer Änderung erneut auszuführen, hilft, eine Regression zu finden: einen Fehler in einem Verhalten, das zuvor funktionierte.

Erstelle einen Jupiter-Test

JUnit Jupiter ist das Programmiermodell von JUnit 5 und 6. JUnit 6 benötigt Java 17 oder neuer. Testannotationen und Assertions verwenden org.junit.jupiter.api.

Lege ShippingCalculatorTest.java unter src/test/java/com/example/parcels/domain ab, mit derselben Paketdeklaration wie der Rechner. Das separate Quellverzeichnis hält Tests vom ausgelieferten Programmcode getrennt und erhält zugleich den Zugriff innerhalb desselben Pakets.

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);
    }
}

Die Testklasse und die Methode können Paketzugriff haben. Eine Testmethode gibt void zurück und darf nicht privat sein. Verwende das @Test von Jupiter; org.junit.Test aus JUnit 4 gehört zu einem anderen Programmiermodell und wird von der Jupiter-Engine nicht erkannt. JUnit-4-Assertions können funktionieren, wenn ihre Bibliothek verfügbar ist; einheitliche Jupiter-Importe halten die Einrichtung jedoch übersichtlich.

Lies das Arrange-Act-Assert-Muster

Der erste Teil bereitet einen Rechner vor. Der zweite führt die Aktion aus, indem er die Gebühr abfragt. Die abschließende Assertion vergleicht die erwarteten 500 Cent mit dem zurückgegebenen Wert. Leerzeilen machen diese Aufgaben gut erkennbar. Würde nur fee ausgegeben, müsste eine Person entscheiden, ob der Wert korrekt ist; die Assertion macht diese Entscheidung zum Teil des Tests.

Bei assertEquals(expected, actual) steht zuerst die Anforderung und danach das beobachtete Ergebnis. Eine optionale Meldung steht zuletzt, wie in assertEquals(500, fee, "fee for 1,500 g"). Werden die ersten beiden Argumente vertauscht, ändert sich für diese Werte gewöhnlich nicht, ob der Test besteht oder fehlschlägt, aber die Bedeutung der Fehlermeldung wird umgekehrt.

Wähle die passende Assertion

Verwende assertTrue oder assertFalse für einen booleschen Wert und assertNull oder assertNotNull, wenn das Vorhandensein eines Objekts das Ergebnis ist. Prüfungen auf Objektgleichheit verwenden equals; ohne Überschreibung können zwei verschiedene Objekte mit übereinstimmenden Feldern trotzdem als ungleich gelten.

Gleitkommaergebnisse benötigen eine passende Toleranz. Die Rechnung 0.1 + 0.2 ergibt in einem Java-double den Wert 0.30000000000000004:

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

Das dritte Argument erlaubt eine absolute Differenz von bis zu 0.000000001. Wähle eine zur Berechnung passende Toleranz; eine zu große Toleranz kann einen bedeutsamen Fehler verbergen. Ganzzahlige Centberechnungen benötigen keine Dezimaltoleranz.

Lies einen Fehlschlag

Führe einen Test über die IDE oder das Build-Werkzeug aus. Ein Bericht wie „expected: <500> but was: <900>“ nennt das geforderte und das beobachtete Ergebnis; der Stacktrace verweist auf die Assertion. Eine unerwartete Ausnahme lässt einen Test ebenfalls fehlschlagen. Grün bedeutet, dass die geprüften Fälle bestanden haben; die Auswahl dieser Fälle bleibt ein eigener Teil des Testens.

Eine nützliche Testauswahl prüft, wie die Spezifikation Eingaben in Fälle aufteilt. Eine gewöhnliche Eingabe testet selten eine ganze Regel. Grenzwertfälle direkt an einer Grenze und unmittelbar daneben eignen sich besonders, um eine Bedingung mit einem falschen Vergleichsoperator aufzudecken.

Teile den Eingabebereich auf

Eine Äquivalenzklasse gruppiert Eingaben, die gleich behandelt werden sollen. Die Versandregel hat ungültige Gewichte bei null oder darunter, eine Gebührenstufe von 500 Cent bis einschließlich 2.000 g, eine Stufe von 900 Cent bis einschließlich 10.000 g und darüber eine Berechnung mit angefangenen Blöcken. Wähle repräsentative Eingaben aus den Klassen und prüfe dann ihre Grenzen.

Eine Änderung von <= 2000 zu < 2000 wirkt sich bei genau 2.000 g aus. Ein Test bei 1.500 g besteht weiterhin. Teste oberhalb von 10.000 g sowohl einen ganzen Block als auch das erste Gramm des nächsten Blocks, um das Aufrunden zu prüfen.

Erwartete Werte stammen aus der Anforderung und einer Rechnung von Hand. Bei 12.500 g beträgt der Überschuss 2.500 g, sodass drei angefangene Blöcke nötig sind und das erwartete Ergebnis 1.200 Cent beträgt. Würdest du die Methode ausführen und ihre Antwort in den Test kopieren, würdest du auch jeden Fehler übernehmen.

Teste zurückgewiesene Eingaben

Ein Ausnahmetest übergibt JUnit die auszuführende Operation:

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

Der Ausdruck () -> ... ist ein Lambda-Ausdruck: ein kleines Stück Code, das an JUnit übergeben wird. JUnit führt ihn innerhalb der Prüfung aus. Würdest du die Methode aufrufen, bevor du sie an die Assertion übergibst, würde die Ausnahme entweichen, bevor die Prüfung sie untersuchen kann.

assertThrows akzeptiert den angegebenen Ausnahmetyp oder eine Unterklasse. Die Prüfung schlägt fehl, wenn die Operation normal endet oder eine Ausnahme eines inkompatiblen Typs wirft. Sie gibt die Ausnahme zurück, sodass eine geforderte Meldung geprüft werden kann:

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

Gib einem Szenario einen lesbaren Namen

Namen wie zeroWeightIsRejected und feeIsBaseFeeAtExactly2000Grams bezeichnen das vorgesehene Verhalten. Ein Test kann mehrere Assertions haben, wenn sie dasselbe Ergebnis prüfen. Nachdem einer Sendung Pakete mit 1.200 g und 800 g hinzugefügt wurden, beschreibt die Prüfung einer Anzahl von zwei und eines Gesamtgewichts von 2.000 g dieses eine Szenario. assertAll kann Prüfungen gruppieren, sodass alle Fehlschläge gemeldet werden.

Prüfe veränderte Objekte über ihr Verhalten, etwa parcelCount() und totalWeightGrams(), statt private Felder für Tests freizugeben. Ein Refactoring kann dann Speicherdetails ändern und die Prüfungen erhalten. Vollständige Zeilenabdeckung bedeutet, dass die Tests die Zeilen ausgeführt haben; ein falscher Grenzwert oder eine ungetestete ungültige Eingabe kann trotzdem übersehen werden.

Jeder Test sollte alles vorbereiten, was er benötigt. Ein Test, der nur besteht, nachdem ein anderer Test Daten hinzugefügt hat, hängt von einer verborgenen Vorgeschichte ab. Solchen Tests lässt sich schwer vertrauen, wenn das Werkzeug zur Testausführung die Reihenfolge ändert oder nur eine Methode ausführt.

Erzeuge eine neue Fixture

Eine Fixture ist die Gesamtheit der Objekte und Daten, die ein Test verwendet. Lege wiederholte Vorbereitungen pro Test in @BeforeEach ab:

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());
    }
}

Die Vorbereitung läuft vor jeder Methode. Der zweite Test verändert nicht die Sendung, die der erste verwendet. Standardmäßig erzeugt Jupiter außerdem für jede Testmethode eine neue Instanz der Testklasse. Veränderliche statische Felder bleiben gemeinsam genutzt, sodass eine statische Liste weiterhin Zustand zwischen diesen Instanzen übertragen kann.

@AfterEach führt Aufräumarbeiten nach jedem Test durch. @BeforeAll und @AfterAll laufen einmal für die Klasse und sind im standardmäßigen Lebenszyklus statisch. Gemeinsam genutzte schreibgeschützte Referenzdaten können sich für eine einmalige Vorbereitung pro Klasse eignen; veränderliche Objekte müssen gewöhnlich für jeden Test neu erzeugt werden. Tests müssen einzeln funktionieren, ohne von der Reihenfolge in der Quelldatei abzuhängen.

Verwende einen Testrumpf für eine Tabelle

Ein parametrisierter Test führt dieselbe Verhaltensprüfung für mehrere Zeilen aus:

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

Jede Zeile ist ein eigener Aufruf mit einem eigenen Bericht. @ValueSource(ints = {0, -5}) liefert für Tests ungültiger Eingaben eine Ganzzahl pro Aufruf. Annotationen für parametrisierte Tests stammen aus org.junit.jupiter.params; CsvSource und ValueSource liegen in dessen Paket provider. Die Sammelabhängigkeit junit-jupiter enthält das Modul für parametrisierte Tests.

@DisplayName ergänzt eine lesbare Bezeichnung im Bericht. @Disabled erfasst einen übersprungenen Test mit einer Begründung; eine übersprungene Prüfung liefert keinen Beleg dafür, dass das zu prüfende Verhalten funktioniert.

Steuere die Umgebung

Ein Service-Test kann ein InMemoryParcelRepository erhalten, einen funktionierenden Fake, der Pakete im Arbeitsspeicher speichert. Das vermeidet echte Dateiinhalte und isoliert die Logik. Übergib einer Textoberfläche einen aus einem bekannten String erzeugten Scanner, wenn du ihre Eingabeverarbeitung testest. Ebenso macht ein festes Datum oder ein Random mit festem Startwert eine externe Eingabe vorhersagbar.

Ein Flaky Test ändert sein Ergebnis zwischen Ausführungen, ohne dass der Code relevant geändert wurde. Gemeinsam genutzte veränderliche Daten, die aktuelle Zeit, unkontrollierte Zufallswerte und zurückgelassene Dateien sind häufige Ursachen. Gib dem Test die Kontrolle über diese Eingaben. Halte Hilfsmethoden klein und die Vorbereitung lesbar; eine Fixture, die viele nicht zusammengehörige Objekte erzeugt, kann zeigen, dass die getestete Klasse zu viele Aufgaben hat.

Testgetriebene Entwicklung (TDD) beginnt eine Verhaltensänderung mit einem Test. Ein kurzer Zyklus macht das fehlende Verhalten sichtbar, implementiert es und verbessert anschließend die Struktur des Codes. Eine Testliste hält noch zu untersuchende Fälle fest, ohne dass sie alle auf einmal geschrieben werden müssen.

Nimm einen Eintrag aus der Testliste

Notiere für eine Prüfung auf Schaltjahre im gregorianischen Kalender vier Verhaltensweisen: ein gewöhnliches Nichtschaltjahr, ein durch vier teilbares Jahr, ein Jahrhundertjahr, das nicht durch 400 teilbar ist, und ein Jahrhundertjahr, das durch 400 teilbar ist. Diese Fälle stehen für verschiedene Teile der Regel.

Rot: Schreibe einen Test und führe ihn aus. Eine fehlende Methode kann einen Kompilierfehler verursachen. Sobald die Methode existiert, prüfe, ob der Test für das Verhalten fehlschlägt, das du ergänzen möchtest. Eine fehlende Assertion, der falsche Methodenaufruf oder ein nicht erkannter Test können ein scheinbar grünes Ergebnis irreführend machen. Ein neuer Fall kann auch bereits durch bestehenden Code erfüllt sein; untersuche dieses Ergebnis, bevor du die Implementierung änderst.

Grün: Ergänze den einfachsten Code, mit dem der neue Test und alle vorherigen Tests bestehen. Refactoring: Verbessere die Struktur, ohne das Verhalten zu ändern, und führe die Tests nach jeder kleinen Änderung erneut aus. Wähle dann den nächsten Fall.

Lass die Fälle die Regel entwickeln

Die erste Prüfung ist assertFalse(LeapYears.isLeapYear(2023)). Erstellst du die Methode mit return false;, besteht dieser Fall. Das ist ein bewusster erster Schritt und noch keine fertige Kalenderregel.

Die nächste Prüfung, assertTrue(LeapYears.isLeapYear(2024)), schlägt fehl. Ändere die Methode zu return year % 4 == 0;. Beide Fälle bestehen nun.

Anschließend deckt assertFalse(LeapYears.isLeapYear(1900)) die Ausnahme für Jahrhundertjahre auf. Änderst du den Ausdruck zu year % 4 == 0 && year % 100 != 0, bestehen diese drei Tests.

Schließlich deckt assertTrue(LeapYears.isLeapYear(2000)) die Ausnahme von der Jahrhundertregel auf. Die Implementierung lautet nun:

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

Führe nach der Änderung alle vier Prüfungen aus. Jeder neue Fehlschlag wies auf einen fehlenden Teil des Verhaltens hin, statt dich eine große unvollendete Implementierung nach Fehlern durchsuchen zu lassen.

Verbessere die Struktur in der grünen Phase

Refactoring ändert Namen oder die Struktur und erhält dabei das Verhalten. Eine Methode umzubenennen, eine Hilfsmethode zu extrahieren, wiederholte Logik zu entfernen und eine Klasse in ein besser geeignetes Paket zu verschieben, sind Refactorings, wenn das beobachtbare Verhalten gleich bleibt. Die an einem Grenzwert berechnete Gebühr zu ändern, ist eine Verhaltensänderung und benötigt einen Test, der diese Änderung beschreibt.

Wenn eine Bereinigung einen Test fehlschlagen lässt, stelle das vorgesehene Verhalten wieder her, bevor du eine weitere Funktion ergänzt. Kleine Änderungen helfen, die Ursache eines Fehlschlags zu finden. Ohne Bereinigung bleibt funktionierender Code zurück, der sich zunehmend schwerer erweitern lässt; eine große Implementierung für viele zukünftige Fälle erzeugt mehr Code, den du beim Fehlschlag der nächsten Prüfung untersuchen musst.

TDD hängt von der Qualität der Anforderungen und ausgewählten Fälle ab. Eine missverstandene Regel kann sowohl im Test als auch in der Implementierung erscheinen. Logik mit klaren Ein- und Ausgaben ist ein nützlicher Ausgangspunkt, weil sich das erwartete Ergebnis unabhängig angeben und schnell prüfen lässt.

Ein Build-Werkzeug wandelt Quelldateien in ein geprüftes, paketiertes Ergebnis um. Maven liest eine Projektbeschreibung, lädt deklarierte Bibliotheken herunter, kompiliert Code, führt Tests aus und erzeugt ein Artefakt. Dieselbe Beschreibung gibt der Befehlszeile und der IDE eine gemeinsame Sicht auf das Projekt.

Verwende die Standardstruktur

Lege Java-Programmcode in src/main/java, Tests in src/test/java, Programmressourcen in src/main/resources und Testdaten in src/test/resources ab. Paketverzeichnisse beginnen unterhalb des jeweiligen Java-Quellverzeichnisses. Maven schreibt erzeugte Ausgaben unter target; bearbeite die Quelldateien, nicht die kompilierten Kopien in diesem Verzeichnis.

Die Datei pom.xml im Projektwurzelverzeichnis, das Project Object Model, identifiziert das Projekt anhand von Koordinaten: groupId, artifactId und version. Beispielsweise bezeichnet com.example:parcels:1.0-SNAPSHOT eine Entwicklungsversion des Paketprogramms. Auch eine Bibliotheksabhängigkeit hat Koordinaten.

Deklariere JUnit für Tests

Das Folgende ist eine vollständige kleine Maven-Konfiguration. Sie kompiliert für Java 17 und wählt ein Werkzeug zur Testausführung, das Jupiter unterstützt:

<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 ruft Abhängigkeiten aus Repositorys ab, normalerweise aus Maven Central, und speichert sie unter .m2/repository in deinem Benutzerverzeichnis zwischen. Bibliotheken, die eine Abhängigkeit benötigt, sind transitive Abhängigkeiten. Der Test-Abhängigkeitsbereich macht JUnit zum Kompilieren und Ausführen von Tests verfügbar, nicht zum Kompilieren des Hauptcodes oder im Klassenpfad des Programms zur Laufzeit. Eine gewöhnliche JAR-Datei hält die JAR-Dateien ihrer Abhängigkeiten getrennt, sofern die Paketierung nicht so konfiguriert ist, dass sie diese bündelt.

Fordere eine Lebenszyklusphase an

Der Hauptlebenszyklus durchläuft unter anderem die Phasen Kompilieren, Testen, Paketieren und Installieren. Wird package angefordert, laufen auch frühere Phasen. Mit dem Wrapper kompiliert und testet ./mvnw test; ./mvnw package erzeugt außerdem die JAR-Datei unter target; ./mvnw install legt das Artefakt zusätzlich im lokalen Repository ab. Der separate Bereinigungslebenszyklus ./mvnw clean entfernt erzeugte Ausgaben.

Ein Testfehlschlag stoppt den normalen Build, bevor ein neues Artefakt paketiert wird. Eine ältere JAR-Datei kann bis zur Bereinigung noch vorhanden sein; ihr Vorhandensein belegt daher nicht, dass der letzte Build erfolgreich war.

Mache die Testerkennung sichtbar

Zu den Standardmustern von Surefire gehören Namen, die mit Test beginnen oder auf Test, Tests oder TestCase enden. ShippingChecks passt nicht dazu; verwende ShippingCalculatorTest und prüfe die gemeldete Testanzahl. Tests unter src/main/java können keine Abhängigkeit mit Test-Abhängigkeitsbereich verwenden.

Der Maven Wrapper, mvnw oder unter Windows mvnw.cmd, führt die vom Projekt festgelegte Maven-Version aus. Verwende ein Projekt, das seine Wrapper-Dateien enthält; eine POM allein erzeugt die Skripte nicht. Vom Projektwurzelverzeichnis aus stellt der Wrapper einen einheitlichen Build-Befehl ohne separate Maven-Installation bereit.

Gradle beschreibt einen Build mit einem Skript und führt Tasks mit ihren Abhängigkeiten aus. Ein Kotlin-Skript heißt build.gradle.kts; ein Groovy-Skript heißt build.gradle. Plugins stellen Tasks bereit, und Abhängigkeitskonfigurationen geben an, wo Bibliotheken benötigt werden.

Konfiguriere eine Anwendung und Jupiter

Eine settings.gradle.kts im Projektwurzelverzeichnis kann rootProject.name = "parcels" enthalten. Ein passendes Kotlin-Build-Skript lautet:

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()
}

Das Plugin application stellt Java-Build-Tasks bereit und ergänzt run. mavenCentral() wählt ein Repository für Abhängigkeiten aus. Die BOM, eine Bill of Materials, stimmt die Versionen der JUnit-Module aufeinander ab, sodass die Version einmal erscheint. testImplementation stellt Bibliotheken bereit, die zum Kompilieren und Ausführen von Tests benötigt werden. testRuntimeOnly stellt den Launcher nur bei deren Ausführung bereit. Bibliotheken für den Hauptcode verwenden implementation, wodurch sie auch für Testcode verfügbar werden.

useJUnitPlatform() wählt die Plattform aus, auf der Jupiter-Tests ausgeführt werden. Werden Jupiter-Bibliotheken hinzugefügt, ohne das Werkzeug zur Testausführung zu konfigurieren, bleiben diese Tests möglicherweise unentdeckt. Aktuelles Gradle schlägt bei seiner Standardeinstellung fehl, wenn Testquellen existieren, aber keine Tests erkannt werden; prüfe die Ausgabe und Konfiguration des Test-Tasks, statt die Prüfung zu entfernen.

Führe Tasks mit dem Wrapper aus

Verwende den mit dem Projekt gelieferten Wrapper: ./gradlew test führt Tests aus; ./gradlew build kompiliert, testet und paketiert; ./gradlew run startet die konfigurierte Hauptklasse; und ./gradlew clean entfernt build. Unter Windows wird gradlew.bat verwendet. Gradle verwendet dieselbe Struktur für Haupt- und Testquellen wie Maven und schreibt erzeugte Ausgaben nach build.

Bei einem mit UP-TO-DATE markierten Task haben sich die erfassten Ein- und Ausgaben nicht geändert, sodass Gradle sein früheres Ergebnis wiederverwendet. Diese Meldung unterscheidet sich von einem neu ausgeführten Testlauf. Der HTML-Testbericht liegt unter build/reports/tests/test/index.html.

Finde die fehlgeschlagene Phase

Beginne mit dem frühesten hilfreichen Fehler. „Cannot find symbol“ beim Kompilieren des Hauptcodes deutet auf den genannten Code, einen Import oder eine Abhängigkeit hin. Fehlt org.junit.jupiter.api beim Kompilieren der Tests, deutet das auf die Einrichtung der Testabhängigkeit hin; derselbe Fehler beim Kompilieren des Hauptcodes kann bedeuten, dass ein Test im Hauptquellverzeichnis abgelegt wurde. Ein Fehler bei der Auflösung von Abhängigkeiten deutet auf Koordinaten, Repository-Zugriff oder Netzwerkverfügbarkeit hin.

Ein Fehlschlag bei der Testausführung ist etwas anderes: Der Test wurde kompiliert und erkannt, aber seine Prüfung ist fehlgeschlagen. Erscheint „expected: <500> but was: <900>“ am Gebührenwert von 2.000 g, prüfe den Vergleich, der die Gebührenstufe auswählt. Eine Änderung der Abhängigkeiten behebt diese Berechnung nicht.

Maven bietet eine deklarative XML-Beschreibung mit festen Lebenszyklusphasen. Gradle bietet konfigurierbare Skripte und Tasks und überspringt dabei auch Arbeit, deren Ergebnisse aktuell sind. Beide automatisieren wiederholbare Java-Builds; verwende das für das Projekt gewählte Werkzeug und lies den ersten Fehler, den du beheben kannst, bevor du Code änderst.