Wie testet man ein SwiftUI-Projekt mit Swift Testing? 2026-Einsteiger-Tutorial für Xcode 27

1. Das Testziel vor der Oberfläche festlegen

Swift Testing eignet sich zunächst für Regeln im Code, die sich ohne Tippen, Wischen oder Anzeigen einer Ansicht überprüfen lassen. Eine laufende App kann trotzdem einen Fehler enthalten: Wenn eine Punkteanzeige nach einer Eingabe einen Wert darstellt, der sich lediglich aus einem veralteten Zustand ergibt, beweist die korrekte Darstellung noch nicht, dass die Punkte-Regel richtig rechnet. Apple zeigt in seinem Swift-Testing-Lernprojekt für eine Punkte-App, wie sich Funktionen einer solchen App gezielt mit Tests prüfen lassen.

Ein Unit-Test ist mit der Korrektur einer einzelnen Aufgabe vergleichbar: Er prüft eine klar abgegrenzte Regel, nicht den gesamten Kurs. Für ein Lernprojekt kommen zum Beispiel eine Berechnung, eine Eingabeprüfung oder ein Zustandswechsel infrage. Wählen Sie etwas, dessen erwartetes Ergebnis sich vorab in einem Satz ausdrücken lässt.

Die Oberfläche hat eine andere Aufgabe. Ein Logiktest kann prüfen, ob eine Funktion einen richtigen Wert liefert. Er beantwortet nicht, ob ein Button mit dieser Funktion verbunden ist, ob die Ansicht nach der Berührung aktualisiert wird oder ob sich die App im Simulator so bedienen lässt, wie es die Aufgabe verlangt. Ein bestandener Unit-Test ist deshalb kein vollständiger App-Test.

Bevor Sie Code verschieben, markieren Sie die konkrete Regel, die geprüft werden soll. Wenn Berechnung und Darstellung im selben View-Code vermischt sind, lässt sich die Berechnung möglicherweise nicht unabhängig aufrufen. Dann ist es meist klarer, die Regel in eine Funktion oder einen kleinen Typ außerhalb der View zu verlegen. Ziel ist nicht, eine große Architektur aufzubauen, sondern den prüfbaren Teil sichtbar und wiederverwendbar zu machen.

2. Eine einzelne Regel aus dem View-Code lösen

Für das Beispiel dient eine kleine Punkte-Regel: Ein Ergebnis darf nicht unter null fallen. Diese Regel ist leicht zu verstehen und hat sowohl eine normale Eingabe als auch einen Randfall. Ein Grenzfall ist wie eine Aufgabe am Rand des erlaubten Bereichs: Er prüft, ob die Regel auch dann stimmt, wenn ein Wert eine Grenze erreicht oder überschreiten würde.

Legen Sie die Berechnung in einen Typ, den sowohl die App als auch das Testziel verwenden können. Das Beispiel enthält bewusst keine Ansichten und keine Eingabe über den Bildschirm:

struct ScoreRules {
    static func add(points: Int, to score: Int) -> Int {
        max(0, score + points)
    }
}

Die Funktion erhält zwei Werte und gibt ein Ergebnis zurück. Eine normale Eingabe prüft, ob Punkte korrekt addiert werden; eine negative Veränderung bei einem niedrigen Punktestand prüft, ob das Ergebnis an der vorgesehenen Untergrenze bleibt. Die Zahlen im folgenden Testcode sind illustrative Testwerte für diese Regel, keine Leistungs- oder Versionsangaben.

Vor dem Schreiben des Tests hilft diese kurze Aufgaben-Kontrolle:

• Gegeben: Welche Werte erhält die Funktion? Notieren Sie den Ausgangspunktestand und die Veränderung.
• Ausgeführt: Welche Funktion wird mit genau diesen Werten aufgerufen?
• Geprüft: Welches konkrete Ergebnis muss herauskommen?
• Begründet: Warum folgt dieses Ergebnis aus der Regel und nicht nur aus dem aktuellen Verhalten des Codes?

Das erwartete Ergebnis sollte aus der Aufgabenstellung oder Ihrer bewusst festgelegten Regel folgen. Schreiben Sie nicht einfach den Wert auf, den der aktuelle Code liefert; sonst könnte ein Fehler in der Berechnung unbemerkt zum Maßstab des Tests werden.

Wenn eine Berechnung nur deshalb schwer zu testen ist, weil sie in einer langen View-Funktion steckt, teilen Sie nicht blind den gesamten Bildschirmcode auf. Isolieren Sie zuerst nur die Regel, die Sie tatsächlich wiederverwenden oder kontrollieren müssen. Die App kann weiterhin für Darstellung und Bedienung zuständig sein, während die separate Funktion die Berechnung übernimmt.

3. Die richtige Prüfart auswählen

Nicht jede Aufgabe verlangt dieselbe Prüfung. Verwenden Sie die folgende Entscheidungshilfe, bevor Sie Testcode schreiben. Sie verhindert, dass ein Logiktest als Ersatz für einen Simulatorlauf behandelt wird oder eine manuelle Prüfung eine wiederholbare Regelkontrolle ersetzen soll.

• [ ] Wählen Sie einen Swift-Testing-Unit-Test, wenn Sie eine Funktion, Berechnung, Eingabeprüfung oder Zustandsregel mit bestimmten Werten und einem erwarteten Ergebnis prüfen möchten. Beispiel: Eine Punkte-Funktion soll bei einer Eingabe den festgelegten Punktestand zurückgeben.
• [ ] Wählen Sie zusätzlich eine manuelle Prüfung im Simulator, wenn die Aufgabe auch das Verhalten einer SwiftUI-Ansicht einschließt: etwa ob eine Eingabe angenommen wird, eine Schaltfläche reagiert oder die Anzeige nach einer Aktion aktualisiert wird.
• [ ] Prüfen Sie die Kursvorgabe gesondert, wenn ein bestimmtes Gerät, ein bestimmter Simulator oder eine zusätzliche Abnahme verlangt wird. Ein bestandener Logiktest ersetzt eine ausdrücklich verlangte Geräteprüfung nicht.
• [ ] Verschieben Sie noch keinen komplizierten View-Code, wenn sich die relevante Regel bereits unabhängig aufrufen lässt. Trennen Sie Logik nur so weit, wie es für eine klare, wiederholbare Prüfung erforderlich ist.
• [ ] Klären Sie zuerst das Testziel, wenn Xcode keinen Test anzeigt. Ein Fehler in der Zielzuordnung ist ein anderer Fehler als eine falsche Berechnung oder eine unpassende Erwartung.

Als Entscheidung in einem Satz gilt: Ist das erwartete Ergebnis einer isolierten Regel entscheidend, beginnen Sie mit Swift Testing; ist die Bedienung oder Darstellung entscheidend, ergänzen Sie eine Prüfung im Simulator; verlangt der Kurs ein Gerät, führen Sie auch diese Abnahme aus. Diese Prüfarten ergänzen einander, sie konkurrieren nicht um den einen richtigen Weg.

4. Das passende Testziel in Xcode prüfen

Ein Testziel ist der eigene Bereich eines Xcode-Projekts, in dem Testdateien und Einstellungen für deren Ausführung liegen. Es ist mit einem getrennten Aufgabenordner vergleichbar: Der App-Code gehört in den Bereich der App, der Testcode in den Bereich, den Xcode für Tests ausführt. Apple erläutert wie Tests zu einem Xcode-Projekt hinzugefügt werden und beschreibt auch die Konfiguration eines zusätzlichen Projektziels.

Gehen Sie nicht automatisch davon aus, dass jedes Projekt dasselbe Ziel oder dieselben Dateinamen verwendet. Öffnen Sie die Projekteinstellungen und prüfen Sie zuerst, ob es bereits ein geeignetes Testziel gibt. Bei einem neu angelegten Projekt kann Xcode eine Testkonfiguration bereitstellen; bei einem bestehenden Übungsprojekt müssen Sie feststellen, ob die erforderliche Teststruktur schon vorhanden ist oder ergänzt werden muss.

Kontrollieren Sie anschließend diese Punkte:

• Die Testdatei ist dem Testziel zugeordnet und nicht versehentlich nur dem App-Ziel.
• Der Test kann das Modul des eigenen App-Projekts importieren. Der tatsächliche Modulname kann von dem unten verwendeten Beispiel abweichen.
• Das Testing-Modul wird in der Testdatei importiert.
• Die Testfunktion ist in der Form deklariert, die Swift Testing erkennt.
• Die Projektkonfiguration verwendet eine mit der installierten Xcode-Version kompatible Umgebung.

Für Xcode 27 sollten Sie die tatsächlich installierte Version und die dazugehörigen Anforderungen anhand der offiziellen Xcode-Systemanforderungen prüfen. Verlassen Sie sich bei einer Anleitung nicht auf einen Menüpfad, den eine andere Xcode-Version möglicherweise anders darstellt. Entscheidend ist, dass Testdatei, Testziel und App-Modul richtig verbunden sind; Bezeichnungen und Positionen der Einstellungen können sich ändern.

Bei Kursprojekten, die in einem Schulaccount oder auf einem gemeinsam genutzten Rechner liegen, prüfen Sie zusätzlich, ob Sie Änderungen im Projekt speichern dürfen. Legen Sie Zugangsdaten oder persönliche Informationen nicht in Testeingaben, Ausgaben oder Screenshots ab. Für reproduzierbare Ergebnisse sollten Projektdateien und Testergebnisse dem vorgesehenen Kurs- oder Versionskontrollverfahren folgen. Bei gemeinsam genutzten Umgebungen sollten Sie außerdem klären, wer auf Projektdateien zugreifen kann und wo die Kursvorgaben die Speicherung erlauben.

5. Den ersten Swift-Testing-Test schreiben

Swift Testing stellt mit @Test eine Testdeklaration und mit #expect eine Prüfung des erwarteten Ergebnisses bereit. Apple beschreibt diese Werkzeuge in der Einführung zu Swift Testing und in der Dokumentation zu Erwartungen und Bedingungen. Im Test wird zuerst die Eingabe vorbereitet, danach die Funktion aufgerufen und zuletzt das Ergebnis mit einer Erwartung verglichen.

Eine Testdatei kann für das Beispiel so aussehen:

import Testing
@testable import MeinLernprojekt

@Test
func addPointsKeepsExpectedScore() {
    let result = ScoreRules.add(points: 2, to: 4)
    #expect(result == 6)
}

@Test
func addPointsDoesNotGoBelowZero() {
    let result = ScoreRules.add(points: -3, to: 2)
    #expect(result == 0)
}

Ersetzen Sie MeinLernprojekt durch den tatsächlichen Modulnamen Ihres Projekts. Die erste Funktion kontrolliert eine normale Berechnung, die zweite den zuvor festgelegten Grenzfall. Apple verwendet für ein eigenes Swift-Testing-Beispiel ebenfalls eine kleine Punkte-App; die Beispielwerte hier dienen ausschließlich dazu, die Reihenfolge von Eingabe, Funktionsaufruf und Prüfung zu zeigen.

Eine Erwartung ist die Bedingung, an der das Testergebnis gemessen wird – ähnlich einer klar formulierten Musterlösung. In diesem Beispiel lautet sie sinngemäß: „Der berechnete Punktestand muss dem erwarteten Wert entsprechen.“ Stimmt die Bedingung nicht, meldet Xcode den Test als fehlgeschlagen. Eine Erwartung sollte daher eine Aussage prüfen, die aus der Regel folgt, und keine zufällige Einzelheit der Bildschirmdarstellung.

Wenn Sie @testable import verwenden, muss der Modulname zum App-Ziel passen. Übernehmen Sie ihn nicht ungeprüft aus einer Anleitung. Ist der Import falsch, scheitert der Test bereits beim Übersetzen, bevor die Punkte-Regel überhaupt ausgeführt wird. Das ist ein anderes Problem als eine falsche Erwartung: Im ersten Fall kann der Test den Code nicht erreichen, im zweiten Fall wurde die Prüfung ausgeführt und das Ergebnis entsprach nicht der festgelegten Regel.

6. Tests ausführen und Fehler passend einordnen

Starten Sie die Tests mit der Testfunktion von Xcode und beobachten Sie, ob der Test erkannt, gebaut und ausgeführt wird. Die offizielle Anleitung zum Ausführen von Tests und Interpretieren der Ergebnisse erklärt, wie Testergebnisse in Xcode angezeigt und gelesen werden. Menübezeichnungen und die konkrete Darstellung können je nach Projekt und Xcode-Version variieren; prüfen Sie daher die aktuelle Dokumentation, statt sich auf einen ungeprüften Klickpfad zu verlassen.

Wenn kein Test auftaucht, prüfen Sie in dieser Reihenfolge:

1. Gehört die Datei wirklich zum Testziel?
2. Ist Testing importiert?
3. Ist die Testfunktion mit @Test markiert?
4. Ist das Testziel in der aktuellen Testauswahl enthalten?
5. Kann der Test das App-Modul mit dem richtigen Namen importieren?

Wenn ein Test erscheint, aber fehlschlägt, lesen Sie zuerst die angezeigte Erwartung und den tatsächlichen Wert. Vergleichen Sie dann die Eingabewerte mit der Aufgabenregel. Häufig wurde entweder ein anderer Ausgangswert vorbereitet als beabsichtigt, eine falsche Funktion aufgerufen oder das Ergebnis in der Erwartung falsch notiert.

Auch ein Fehler beim Übersetzen ist nicht dasselbe wie ein Fehler in der Logik. Ein nicht gefundenes Modul deutet zunächst auf Import oder Zielkonfiguration. Eine erfolgreich ausgeführte Testfunktion mit falschem Ergebnis weist eher auf Eingabe, Regel oder erwarteten Wert. Diese Unterscheidung verhindert, dass Sie ohne Anhaltspunkt Bereinigungen oder Neuinstallationen versuchen, obwohl lediglich eine Datei dem falschen Ziel zugeordnet ist.

Die Ergebnisanzeige sollte Teil Ihrer Lernnotizen sein: Halten Sie fest, welche Regel geprüft wurde, welche Eingabe Sie verwendet haben und ob der Test bestanden oder fehlgeschlagen ist. So lässt sich derselbe Test später erneut ausführen und mit Änderungen am Code vergleichen, ohne dass Sie sich nur auf eine Erinnerung an den letzten Simulatorlauf verlassen müssen.

7. Logikprüfung und App-Abnahme getrennt abschließen

Nach den Logiktests starten Sie die App gesondert und prüfen die Bedienung, die für die Aufgabe wichtig ist. Ein Test kann belegen, dass ScoreRules einen passenden Wert berechnet; er bestätigt nicht, dass die View den Wert nach einer Aktion neu anzeigt. Prüfen Sie daher, ob die Eingabe ankommt, die Oberfläche den neuen Zustand zeigt und sich der relevante Ablauf wie vorgesehen bedienen lässt.

Für den Kursabschluss lassen sich die Ergebnisse in drei getrennte Aussagen gliedern:

• Logiktest bestanden: Die geprüften Regeln lieferten für die vorgesehenen Eingaben die erwarteten Ergebnisse.
• App im Simulator ausgeführt: Das Projekt ließ sich in der simulierten Umgebung starten und die relevanten Interaktionen konnten geprüft werden.
• Kurs- oder Geräteabnahme erfüllt: Die Lehrveranstaltung oder Aufgabenbeschreibung verlangte keine zusätzliche Prüfung, oder die ausdrücklich geforderte Geräteprüfung wurde ebenfalls durchgeführt.

Diese Aussagen sind nicht austauschbar. Wenn die Aufgabe einen Simulatorlauf verlangt, ersetzt ein grüner Unit-Test diesen Schritt nicht. Wenn zusätzlich ein echtes Gerät vorgeschrieben ist, sollten Sie erst nach den Kursvorgaben entscheiden, ob die lokale Umgebung dafür genügt. Notieren Sie nötigenfalls, welche Tests und welche manuelle Prüfung tatsächlich erfolgt sind, statt „App getestet“ als ungenaue Sammelaussage zu verwenden.

Ein sauberer Abschluss umfasst auch die Projektdaten. Speichern Sie Änderungen im vorgesehenen Projektordner, halten Sie persönliche Schlüssel und Zugangsdaten aus Testcode und Screenshots heraus und beachten Sie die Datenschutzregeln Ihrer Schule oder Ihres Kontos. Wenn ein Rechner gemeinsam genutzt wird, melden Sie sich nach der Arbeit ab und entfernen Sie keine Kursdateien, die andere Lernende noch benötigen. Reproduzierbarkeit entsteht nicht allein durch den Test, sondern auch dadurch, dass Projektstand und Prüfbedingungen nachvollziehbar bleiben.

Im Vergleich zu einer verfügbaren kompatiblen Mac-Umgebung sind virtuelle Umwege oder ein fremder Schulrechner oft mit konkreten Nachteilen verbunden: Die Xcode-Konfiguration ist möglicherweise nicht frei änderbar, Projektdateien und Testergebnisse liegen auf mehreren Geräten, und der Zugriff kann vom Stundenplan oder einer Freigabe abhängen. Für gelegentliche Übungen kann ein bereits vorhandener Mac die einfachste Wahl sein; für dauerhaftes Arbeiten mit wiederkehrenden, größeren Kursprojekten kann ein eigener Mac sinnvoller sein als eine zeitlich begrenzte Umgebung.

Wer noch keinen kompatiblen Mac hat und zunächst nur eine SwiftUI-Aufgabe nachvollziehen möchte, kann die Umgebungsoptionen in der Übersicht von NodeMini prüfen. Falls ein eigener Rechner gerade nicht infrage kommt, lässt sich auch ein zeitlich begrenzter Zugriff auf einen Mac von NodeMini erwägen; für regelmäßige, langfristige Arbeit sollten Sie Mietkosten und Kursanforderungen mit den Kosten und Anforderungen eines eigenen Geräts vergleichen. Details zur verfügbaren Option finden Sie auf der Seite zum Mac-Mieten für Entwicklungsaufgaben.

Häufige Fragen zu Swift Testing und SwiftUI

Wie beginnen Sie mit dem ersten Test?
Wählen Sie eine kleine Berechnung, trennen Sie sie von der View und legen Sie im passenden Testziel einen Test mit Eingabe, Funktionsaufruf und Erwartung an. Beginnen Sie nicht mit der gesamten Oberfläche.

Wohin gehört die Testdatei?
In das Testziel des Projekts. Prüfen Sie die Zielmitgliedschaft der Datei und den Namen des importierten App-Moduls, bevor Sie nach einem Fehler in der Testlogik suchen.

Warum wird kein Test gefunden?
Eine laufende App bedeutet nicht, dass Xcode die Testdatei ausführt. Kontrollieren Sie Zielmitgliedschaft, Testing-Import und @Test-Deklaration sowie die Auswahl des Testziels.

Muss nach bestandenen Unit-Tests noch der Simulator geprüft werden?
Ja, wenn die Oberfläche oder Interaktion Teil der Aufgabe ist. Ein Unit-Test bestätigt nicht, dass Schaltflächen, Zustandsanzeige und App-Ablauf korrekt funktionieren. Prüfen Sie außerdem, ob Kursvorgaben eine Geräteabnahme verlangen.