Swift Testing oder XCTest? Leitfaden für Einsteiger 2026

Swift Testing oder XCTest? Leitfaden für Einsteiger 2026

Der neue Xcode-Testdialog zeigt zwei Möglichkeiten, und die erste Abgabe steht kurz bevor: Swift Testing oder XCTest? Für neue Unit- und Integrationstests ist Swift Testing die Standardwahl; UI-Tests bleiben bei XCTest. Alte Kurse und bestehende Projekte müssen nicht sofort umgeschrieben werden, weil beide Frameworks schrittweise im selben Testziel zusammenarbeiten können.

Dieser Beitrag richtet sich an Swift-, SwiftUI- und iOS-Einsteiger, die erstmals @Test, #expect oder XCTestCase sehen. Er hilft außerdem Studierenden mit alten Kursaufgaben, übernommenen Gruppenprojekten oder einem Windows-Rechner, die Grenze zwischen trainierbarer Swift-Logik und Mac-gebundenen iOS-Tests zu erkennen.

Zuletzt aktualisiert am 18.09.2026. Versions- und Kompatibilitätsangaben wurden anhand der Apple-Dokumentation zu den Xcode-Systemanforderungen, der offiziellen Testdokumentation und der Swift-6.4-Veröffentlichungsnotiz geprüft.

Die schnelle Einordnung: neue Logik gegen sichtbare Oberfläche

Ein Test ist für Einsteiger am einfachsten als automatische Abgabeprüfung zu verstehen. Statt jede Eingabe von Hand zu kontrollieren, lässt sich eine Funktion mit mehreren Beispielen prüfen. Dabei sind zwei Aufgaben zu trennen:

  • Swift Testing prüft neue Unit- und passende Integrationstests. Es ist für neue Testfälle gut geeignet, unterstützt lesbare Prüfungen, parametrische Tests und moderne Swift-Anwendungsfälle.
  • XCTest bleibt für UI-Automatisierung zuständig. Klicks, Texteingaben, Navigation und sichtbare Zustände werden damit geprüft.
  • Bestehende XCTest-Tests dürfen zunächst bestehen bleiben. Eine Migration sollte nur beginnen, wenn Kursvorgaben, Testplan und Abgabeumgebung geklärt sind.

Apple führt für neue Projekte die Auswahl zwischen Swift Testing für Unit Tests und XCTest UI Tests ausdrücklich zusammen. Die Auswahl bedeutet daher nicht „eine Bibliothek gegen die andere“, sondern „welche Aufgabe soll geprüft werden?“ Das beschreibt auch die offizielle Anleitung zum Hinzufügen von Tests in Xcode.

Der erste Test: zwei kleine Prüfregeln

Ein minimales Beispiel zeigt den Unterschied schneller als eine lange Definition. Angenommen, eine Lernaufgabe soll eine Begrüßung erzeugen:

func greeting(for name: String) -> String {
    "Hallo, \(name)"
}

Mit Swift Testing kann der Test so aussehen:

import Testing

@Test
func greetingContainsName() {
    let result = greeting(for: "Mira")
    #expect(result == "Hallo, Mira")
}

@Test markiert die Funktion als Testfall. Das ist vergleichbar mit einem Etikett auf einer Abgabe: Xcode erkennt, dass diese Funktion ausgeführt werden soll. #expect ist die Prüfbedingung. Sie sagt, welches Ergebnis erwartet wird. Die Apple-Erklärung zu Erwartungen in Swift Testing beschreibt diese Prüfungen und ihre Fehlermeldungen.

Der ältere XCTest-Stil verwendet eine Testklasse:

import XCTest

final class GreetingTests: XCTestCase {
    func testGreetingContainsName() {
        let result = greeting(for: "Mira")
        XCTAssertEqual(result, "Hallo, Mira")
    }
}

XCTestCase ist die gemeinsame Hülle mehrerer Testmethoden. XCTAssertEqual vergleicht erwartetes und tatsächliches Ergebnis. Dieser Stil ist nicht falsch. Er ist in vielen Kursen, Vorlagen und vorhandenen Projekten weiterhin wichtig. Die Dokumentation zu XCTest-Fällen und Testmethoden erklärt diese Struktur.

Für neue Lernaufgaben ist Swift Testing meist leichter zu lesen. Das ist aber keine pauschale Aussage, dass jeder alte Test ersetzt werden muss. Entscheidend ist der Abgabekontext.

Die Auswahl nach Personengruppe

Neue SwiftUI- oder iOS-Projekte

Wer ein Projekt neu anlegt und keine Kursvorgabe für XCTest hat, sollte die Logiktests mit Swift Testing beginnen. Die Gründe sind konkret:

  1. Die Testfunktion braucht keine zusätzliche Testklasse.
  2. @Test macht den Zweck direkt sichtbar.
  3. #expect formuliert die Bedingung nahe am geprüften Ergebnis.
  4. Parametrische Tests können mehrere Eingaben mit derselben Testidee prüfen.
  5. Swift Testing passt zu modernen Swift-Programmen und unterstützt geeignete nebenläufige Testfälle.

Ein parametrischer Test kann zum Beispiel mehrere Namen prüfen:

import Testing

@Test(arguments: ["Mira", "Jonas", "Lea"])
func greetingIsNotEmpty(name: String) {
    #expect(!greeting(for: name).isEmpty)
}

Die Idee ähnelt einer Lehrkraft, die dieselbe Aufgabe mit mehreren Zahlen kontrolliert. Die Testregel bleibt gleich, nur die Eingabe ändert sich. Das verhindert, dass ein Programm zufällig nur für ein Beispiel funktioniert.

Für die Oberfläche bleibt XCTest zuständig. Ein UI-Test könnte prüfen, ob eine Schaltfläche eine neue Ansicht öffnet:

import XCTest

final class AppUITests: XCTestCase {
    func testOpeningDetailsScreen() {
        let app = XCUIApplication()
        app.launch()

        app.buttons["Details"].tap()
        XCTAssertTrue(app.navigationBars["Details"].exists)
    }
}

Hier wird nicht nur eine Funktion berechnet. Xcode startet eine Anwendung, findet ein sichtbares Element und führt eine Handlung aus. Deshalb ist die passende Eselsbrücke:

  • Swift Testing: „Ist die Rechen- oder Geschäftslogik richtig?“
  • XCTest UI Tests: „Kann eine Person den vorgesehenen Weg durch die Oberfläche gehen?“

Wer eine neue SwiftUI-App erstellt, sollte also nicht versuchen, beide Aufgaben in ein einziges Framework zu pressen.

Alte Kurse und laufende Abgaben

Wer einem älteren Kurs folgt, sollte nicht wegen eines neuen Frameworks die gesamte Aufgabe umschreiben. Zuerst müssen vier Punkte geklärt werden:

  • Verlangt die Lehrveranstaltung ausdrücklich XCTestCase?
  • Wird ein bestimmtes Testziel oder ein vorhandener Testplan bewertet?
  • Nutzt die Musterlösung XCTest-Hilfsfunktionen?
  • Muss die Abgabe in exakt derselben Xcode-Umgebung geöffnet werden?

Wenn eine Abgabe in wenigen Tagen fällig ist, ist eine Migration normalerweise die falsche Baustelle. Ein Wechsel kann Namenskonventionen, Testberichte, Hilfsfunktionen oder die erwartete Projektstruktur verändern. Die Priorität lautet dann: vorhandene Tests ausführen, Fehler beheben, Projekt reproduzierbar abgeben.

Neue Tests können später mit Swift Testing ergänzt werden. Apple beschreibt die gemeinsame Verwendung beider Systeme und die schrittweise Migration in der Dokumentation zur Testmigration. Das bedeutet praktisch:

  1. Bestehende XCTest-Tests bleiben zunächst unverändert.
  2. Ein kleiner neuer Logiktest wird mit Swift Testing angelegt.
  3. Beide Testarten werden im selben Testziel ausgeführt.
  4. Die Ergebnisse werden vor der Abgabe verglichen.
  5. Erst danach wird entschieden, ob einzelne alte Tests umgebaut werden.

Achtung bei Abgaben: Beginnen Sie keine Migration, wenn die Tests noch nicht als Ausgangsbasis grün laufen. Ohne funktionierende Ausgangsbasis lässt sich später nicht feststellen, ob ein Fehler aus dem Programm oder aus der Umstellung stammt.

Übernommene Gruppenprojekte

Bei einem fremden Repository ist die persönliche Vorliebe kein ausreichendes Entscheidungskriterium. Zuerst sollte der Bestand untersucht werden:

find . -name "*Tests*" -o -name "*UITests*"

Danach folgen in Xcode die Prüfung des Testziels, des Testplans und gemeinsamer Hilfsdateien. Besonders wichtig sind eigene Matcher, Testdaten, Startargumente und Umgebungsvariablen. Ein alter Test kann scheinbar einfach aussehen, aber von einer gemeinsam genutzten Einrichtung abhängen.

Für die Übernahme empfiehlt sich diese Reihenfolge:

  1. Repository lokal oder auf dem Lern-Mac öffnen.
  2. Alle vorhandenen Testziele und Testpläne notieren.
  3. Einen vollständigen Lauf des bestehenden Bestands starten.
  4. Fehlgeschlagene Tests von Warnungen und Einrichtungshinweisen trennen.
  5. Einen neuen, unabhängigen Logiktest mit Swift Testing anlegen.
  6. Den alten und den neuen Lauf unter denselben Bedingungen wiederholen.
  7. Erst bei gleichen Erwartungen einzelne XCTest-Fälle migrieren.

Für Xcode 27 ist die Interoperabilität zwischen den Testframeworks ein offiziell beschriebenes Thema. Die konkrete Ergebnisdarstellung kann jedoch vom Testplan und von der Projektart abhängen. Deshalb reicht es nicht, dass der Build erfolgreich ist. Ein Test gilt erst als geprüft, wenn der Testlauf ihn tatsächlich ausführt und ein absichtlicher Fehler auch als Fehler erscheint.

Ein einfacher Kontrolltest hilft:

@Test
func deliberateFailureCheck() {
    #expect(1 == 2)
}

Dieser Test muss fehlschlagen. Danach wird er wieder gelöscht. Wird er nur als Warnung angezeigt oder gar nicht ausgeführt, ist die Testkonfiguration noch nicht verlässlich.

Entscheidungswerkzeug für die Framework-Wahl

Die folgende Bedingungsliste kann direkt vor dem Anlegen oder Ändern eines Testfalls verwendet werden. Jede Zeile führt zu einer konkreten Auswahl:

  • [ ] Der Test prüft eine reine Swift-Funktion oder eine passende Integration: Swift Testing wählen.
  • [ ] Der Test prüft Schaltflächen, Navigation, Texteingaben oder sichtbare Ansichten: XCTest UI Tests wählen.
  • [ ] Der Kurs verlangt ausdrücklich XCTestCase: XCTest beibehalten und die Abgabe nicht kurzfristig migrieren.
  • [ ] Das Projekt enthält bereits XCTest und soll nur erweitert werden: Beide Frameworks im selben Testziel belassen; neue Logiktests bevorzugt mit Swift Testing schreiben.
  • [ ] Ein Gruppenprojekt besitzt einen festen Testplan: Erst Testplan und Hilfsfunktionen prüfen, danach eine kleine Probeänderung vornehmen.
  • [ ] Der Rechner kann kein Xcode ausführen: Reine Swift-Tests außerhalb des iOS-Projekts üben; UI- und Simulatorprüfungen später auf einem Mac durchführen.
  • [ ] Ein absichtlich falscher Test wird nicht eindeutig als Fehler angezeigt: Nicht migrieren und nicht abgeben, bevor die Testkonfiguration korrigiert ist.

Damit lautet die Kurzentscheidung:

  • Wenn neu und logisch: Swift Testing.
  • Wenn sichtbar und interaktiv: XCTest.
  • Wenn alt und bewertet: XCTest behalten.
  • Wenn gemischt oder übernommen: Koexistenz und schrittweise Migration.
  • Wenn ohne Mac: Swift-Logik vorüben, iOS- und UI-Schritte später auf macOS prüfen.

Dieses Werkzeug verhindert eine häufige Fehlentscheidung: ein Framework nur deshalb zu wechseln, weil es neuer wirkt. Aufgabe, Testziel und Abgaberegel sind wichtiger als die persönliche Vorliebe.

Üben ohne eigenen Mac

Swift Testing ist nicht ausschließlich an eine iOS-Oberfläche gebunden. Swift Packages und reine Swift-Logik können auf unterstützten Plattformen geübt werden. Die Swift.org-Übersicht zu Testing beschreibt den Einsatz im Swift-Package-Umfeld.

Das reicht für Aufgaben wie:

  • Zeichenketten verarbeiten
  • Zahlen und Datumswerte prüfen
  • kleine Datenmodelle testen
  • Sortierung und Filterung kontrollieren
  • Fehlerfälle in einer Funktion simulieren

Es reicht nicht automatisch für:

  • ein SwiftUI-Projekt mit iOS-Ziel
  • den iOS-Simulator
  • Xcode UI Tests
  • Geräteintegration
  • eine Prüfung von Navigation und sichtbaren Bildschirmzuständen

Ein Windows-Lernender kann deshalb zunächst ein kleines Package anlegen und den Testlauf als kontinuierliche Übung verwenden. Vor einer iOS-Abgabe sollte jedoch ein Mac-Schritt eingeplant werden. Der Code muss synchronisiert, im vorgesehenen Projekt geöffnet und mit dem korrekten Testplan ausgeführt werden.

Eine kleine Probeablage reduziert das Risiko:

LearningTests/
├── Package.swift
├── Sources/
│   └── LearningLogic/
└── Tests/
    └── LearningLogicTests/

Der Ablauf ist überschaubar:

  1. Eine reine Swift-Funktion erstellen.
  2. Einen Swift-Testing-Test mit @Test und #expect schreiben.
  3. Den Test lokal ausführen.
  4. Eine absichtliche falsche Erwartung einfügen.
  5. Prüfen, ob der Lauf eindeutig fehlschlägt.
  6. Das Repository auf einem Mac öffnen.
  7. Danach ein kleines Xcode-UI-Projekt mit XCTest UI Tests prüfen.

Wer für diesen letzten Abschnitt keinen eigenen Mac besitzt, kann zeitweise einen echten Remote-Mac verwenden. Bei SFTPMAC lässt sich zunächst die Übersicht der Mac-Zugangsoptionen prüfen. Für eine längere Kursphase ist außerdem ein Vergleich der Mac-Mietpreise sinnvoll. Ein Remote-System ersetzt nicht jede lokale Arbeitsweise: Netzwerkqualität, Zugriffsschutz, Dateiübertragung und eine korrekte Abmeldung müssen eingeplant werden.

FAQ für typische Lernwege

Swift Testing und XCTest im selben Projekt

Ja, die gemeinsame Nutzung ist für eine schrittweise Migration vorgesehen. Neue Unit- und Integrationstests können mit Swift Testing entstehen, während ältere XCTest-Fälle unverändert bleiben. Das Testziel muss beide Frameworks korrekt erkennen. Vor einer Abgabe sollte die vollständige Testsuite im Zielsystem ausgeführt werden, nicht nur der neu geschriebene Test.

Fehlende Mac-Umgebung

Reine Swift-Logik kann in einem unterstützten Swift-Package-Setup geübt werden. Sobald ein iOS-Ziel, SwiftUI, der Simulator oder UI-Automatisierung beteiligt ist, wird eine Xcode-fähige Mac-Umgebung benötigt. Für eine einzelne Projektprüfung kann ein zeitlich begrenzter Remote-Zugriff genügen; für tägliche, langfristige Arbeit ist eine lokale Lösung bequemer.

UI-Prüfungen mit Swift Testing

Swift Testing ist nicht die richtige Wahl für Klick- und Navigationsabläufe. Ein UI-Test muss die Anwendung starten, Elemente finden und Benutzeraktionen ausführen. Diese Aufgaben bleiben bei XCTest UI Tests. Swift Testing kann parallel die dahinterliegende Logik prüfen, etwa ob ein Modell nach einer Eingabe den richtigen Zustand liefert.

Migration einer alten XCTest-Aufgabe

Eine vollständige Migration ist nicht automatisch notwendig. Wenn der Kurs XCTest verlangt oder die Abgabe unmittelbar bevorsteht, bleibt die bestehende Lösung die risikoärmere Basis. Eine spätere Umstellung sollte mit einem einzelnen Test beginnen. Erst wenn Testplan, Fehlermeldungen und Ergebnisdarstellung stimmen, werden weitere Fälle übertragen.

Bedeutung von Swift 6.4

Swift 6.4 ist eine veröffentlichte Swift-Version und gehört zur aktuellen Dokumentationslage dieses Beitrags. Die Versionsnummer entscheidet jedoch nicht allein über das Framework. Prüfen Sie zusätzlich die Xcode-Version, das Zielsystem, die Kursvorgabe und die verwendeten Pakete. Ein älteres Lehrprojekt kann trotz neuer Swift-Version bewusst bei XCTest bleiben.

Die Abgabeprüfung in sieben Schritten

Vor der Abgabe sollte der Lernende nicht nur auf ein grünes Symbol achten. Diese Reihenfolge macht die Prüfung nachvollziehbar:

  1. Projekt öffnen: Das Projekt in der vorgesehenen Xcode-Umgebung starten.
  2. Testziel kontrollieren: Prüfen, ob Quellcode und Tests demselben erwarteten Ziel zugeordnet sind.
  3. Vollständigen Lauf starten: Nicht nur den zuletzt bearbeiteten Test ausführen.
  4. Frameworks trennen: Swift-Testing-Logiktests und XCTest UI Tests in den Ergebnissen unterscheiden.
  5. Fehlerprobe durchführen: Eine Erwartung absichtlich falsch machen und die Fehleranzeige kontrollieren.
  6. UI-Ablauf prüfen: Start, Navigation, Eingabe und Rückkehr zum erwarteten Bildschirm testen.
  7. Ausgangszustand wiederherstellen: Die Fehlerprobe entfernen, Dateien speichern und den vollständigen Lauf erneut ausführen.

Die Apple-Anleitung zum Ausführen und Interpretieren von Tests ist dabei hilfreicher als ein Screenshot eines einzelnen grünen Tests. Ein Screenshot beweist nicht, dass alle Testfälle ausgeführt wurden oder dass die UI-Prüfung im richtigen Testplan lag.

Die passende Umgebung für den nächsten Lernschritt

Für eine neue Swift-Aufgabe ist Swift Testing die klare Wahl für Logik. Für UI-Automatisierung bleibt XCTest notwendig. Für ein altes Kursprojekt ist Koexistenz sicherer als eine übereilte Komplettmigration. Diese Entscheidung schützt die Vergleichbarkeit mit Musterlösung, Lehrkraft und vorhandener Testinfrastruktur.

Ein lokaler Windows-Rechner ist für Swift-Grundlagen und reine Package-Übungen brauchbar. Seine Grenzen liegen bei Xcode, SwiftUI-Projekten, Simulator und UI-Automatisierung. Eine virtuelle macOS-Installation kann zusätzliche Kompatibilitäts-, Lizenz- und Stabilitätsfragen aufwerfen und ist deshalb nicht automatisch der verlässlichste Abgabeweg. Ein eigener Mac bietet die stabilste tägliche Arbeitsumgebung, verursacht aber Anschaffungs- und Wartungskosten.

Wenn nur eine Kursprüfung, ein UI-Test oder eine kurze Migration ansteht, ist ein gemieteter Remote-Mac von SFTPMAC oft die pragmatischere Zwischenlösung: kein Kauf eines Geräts, aber Zugriff auf eine echte macOS-Umgebung. Dafür müssen Netzwerkabhängigkeit, Datenschutz bei Kursdateien und die benötigte Sitzungsdauer realistisch bewertet werden. Bei dauerhaft hoher Nutzung oder notwendiger lokaler Hardware ist ein eigener Mac weiterhin die passendere Entscheidung.

Der sinnvollste nächste Schritt ist klein: ein löschbares Testprojekt anlegen, einen Swift-Testing-Logiktest bestehen lassen, einen XCTest-UI-Test ausführen und erst danach das eigentliche Kursprojekt migrieren. So bleibt klar, ob ein Problem aus dem Code, aus der Testauswahl oder aus der Umgebung stammt.

Weiterführende Artikel