Swift Testing vs XCTest: Der vollständige Migrations-Guide für Xcode 26

Aktualisiert: 9. Juni 2026

Swift Testing ist Apples neues, Macro-basiertes Test-Framework, das XCTest ablöst und in Xcode 26 vollständig integriert ist – es nutzt @Test, #expect und Swift-Concurrency, um Tests kürzer, parallelisierbar und typsicherer zu machen. Eine Migration ist nicht zwingend: Beide Frameworks lassen sich in einem Target koexistieren, sodass du Schritt für Schritt umstellen kannst. Dieser Guide vergleicht beide Frameworks, zeigt die konkrete Migration und beantwortet die häufigsten Fragen zu Parallelisierung, UI-Tests und CI-Integration unter Xcode 26.

• Swift Testing ist seit Xcode 16 stabil und in Xcode 26 mit erweitertem Tooling, Issue-Navigator-Integration und Confirmation-API ausgestattet.
• Statt XCTAssert* nutzt Swift Testing einen einzigen #expect-Macro, der den Ausdruck zerlegt und bei Fehlschlägen die tatsächlichen Werte anzeigt.
• Tests laufen standardmäßig parallel und in beliebiger Reihenfolge – serialisiere bewusst mit .serialized oder @Suite(.serialized).
• XCTest bleibt für UI-Tests (XCUIApplication) und Performance-Tests (measure) erforderlich; beide Frameworks koexistieren im selben Target.
• Parametrisierte Tests via arguments: ersetzen handgeschriebene Schleifen und liefern jeden Fall als separaten Eintrag im Test-Navigator.
• Migration in der Praxis: neue Tests in Swift Testing schreiben, bestehende XCTest-Cases lassen und nur bei größeren Refactors konvertieren.

Was ist Swift Testing?

Swift Testing ist ein quelloffenes Test-Framework, das Apple auf der WWDC 2024 vorgestellt und im Swift-Repository unter swiftlang/swift-testing entwickelt hat. Es nutzt Swift-Macros (@Test, @Suite, #expect, #require) und ist nativ für Swift Concurrency entworfen – jede Testfunktion darf async und throws sein, ohne dass eine spezielle Bridge nötig ist. Im Gegensatz zu XCTest, das 2014 für Objective-C konzipiert wurde, gibt es kein XCTestCase-Subclassing, keine setUp/tearDown-Methoden und keine starre Klassenstruktur.

Stattdessen sind Tests freie Funktionen oder Methoden in struct-Suites, die für jeden Test eine frische Instanz erhalten – das eliminiert eine ganze Kategorie von Bugs durch geteilten Zustand zwischen Tests. Seit Xcode 16 ist das Framework ohne Zusatzabhängigkeit verfügbar; Xcode 26 hat die Integration mit dem Test-Navigator, dem Issue-Navigator und dem Test-Report deutlich ausgebaut, inklusive Live-Anzeige der erfassten Werte aus #expect-Ausdrücken.

Wer sich mit den Sprach-Grundlagen vertraut machen will, sollte zuerst unseren Approachable-Concurrency-Guide für Swift 6.2 durchgehen, da Swift Testing intensiv mit async/await und Aktoren arbeitet.

Swift Testing vs XCTest: Direkter Vergleich

Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber. Beachte, dass Swift Testing nicht alle XCTest-Funktionen abdeckt – insbesondere UI- und Performance-Tests bleiben in XCTest verankert.

Eigenschaft	Swift Testing	XCTest
Test-Deklaration	@Test auf freier Funktion oder Methode	Methode mit Präfix test in XCTestCase
Assertions	Ein Macro: #expect(...) / #require(...)	~40 Funktionen (XCTAssertEqual, XCTAssertTrue, ...)
Async-Unterstützung	Nativ: async/throws in jedem Test	Möglich, aber nachträglich integriert
Parallelisierung	Standard: alle Tests parallel im selben Prozess	Standard seriell, optional parallel pro Prozess
Setup/Teardown	Init und deinit der Suite-struct	setUp() / tearDown() Hooks
Parametrisierte Tests	Eingebaut via arguments:	Manuell mit Schleifen
UI-Tests	Nicht unterstützt	XCUIApplication
Performance-Tests	Nicht unterstützt	measure { ... }
Mindest-Xcode	Xcode 16+, voll in Xcode 26	Alle Xcode-Versionen

Die meisten Teams, die ich begleitet habe, behalten XCTest für Legacy-Tests und schreiben jede neue Test-Suite in Swift Testing – ein Big-Bang-Rewrite lohnt sich selten.

Ersten Swift-Testing-Test in Xcode 26 schreiben

In Xcode 26 ist Swift Testing in jeder neuen App-Vorlage vorausgewählt. Bei einem bestehenden Projekt fügst du es per Datei → Neu → Datei → Unit Test Case (Swift Testing) hinzu. Hier ein minimaler Test einer kleinen Geschäftslogik:

import Testing
@testable import OrderEngine

struct OrderTotalTests {

    @Test("Rabatt von 10 % wird korrekt berechnet")
    func discountApplied() {
        let order = Order(subtotal: 200, discount: 0.10)
        #expect(order.total == 180)
    }

    @Test func steuerWirdAddiert() throws {
        let order = try Order(subtotal: 100, taxRate: 0.19)
        #expect(order.total == 119)
    }
}

Drei Dinge fallen sofort auf. Erstens wird OrderTotalTests als struct deklariert, und Swift Testing erzeugt für jeden Test eine neue Instanz, sodass gemeinsamer Zustand standardmäßig ausgeschlossen ist. Zweitens darf @Test einen menschenlesbaren Titel tragen, der im Test-Navigator und im Test-Report angezeigt wird. Drittens ersetzt #expect sämtliche XCTAssert*-Varianten: der Compiler zerlegt den Ausdruck und meldet bei einem Fehlschlag die tatsächlichen Werte beider Seiten. Ehrlich gesagt war das der Punkt, an dem ich nach zwei Tagen Probieren nicht mehr zurück zu XCTest wollte.

#expect und #require richtig einsetzen

Der zentrale Unterschied zwischen #expect und #require: #expect meldet einen Fehler, lässt den Test aber weiterlaufen – ideal, um mehrere Eigenschaften eines Ergebnisses in einem Durchlauf zu prüfen. #require wirft hingegen einen Fehler und bricht den Test sofort ab; es ist die richtige Wahl, wenn nachfolgende Assertions ohne diesen Wert keinen Sinn ergeben.

@Test func userParsing() throws {
    let json = #"{"id": 42, "name": "Anna"}"#.data(using: .utf8)!
    let user = try #require(try? JSONDecoder().decode(User.self, from: json))

    #expect(user.id == 42)
    #expect(user.name == "Anna")
    #expect(user.isAdmin == false)
}

Bei Fehlschlägen rendert Xcode 26 die zerlegten Werte direkt im Issue-Navigator: Statt „XCTAssertEqual failed: (\"Anna\") is not equal to (\"Bob\")“ siehst du den vollen Ausdruck mit Zwischenresultaten – inklusive Hover-Inspector für komplexe Strukturen. Das spart erfahrungsgemäß die größten Debug-Zeit-Klötze, weil man nicht mehr print-Anweisungen einstreuen muss, um zu sehen, was tatsächlich verglichen wurde.

Für erwartete Fehler verwendest du #expect(throws:):

@Test func negativeBetraegeWerfen() {
    #expect(throws: OrderError.invalidAmount) {
        try Order(subtotal: -10)
    }
}

Parametrisierte Tests und Test-Suites

Einer der größten Produktivitätsgewinne sind parametrisierte Tests. Statt eine Schleife im Test zu schreiben, übergibst du eine Sammlung an arguments:, und Swift Testing erzeugt für jeden Eintrag einen separaten Lauf mit eigenem Pass/Fail-Status:

@Suite("Email-Validierung")
struct EmailValidatorTests {

    @Test(arguments: [
        "[email protected]",
        "[email protected]",
        "[email protected]"
    ])
    func gueltigeAdressen(_ email: String) {
        #expect(EmailValidator.isValid(email))
    }

    @Test(arguments: [
        ("plainstring", false),
        ("@example.de", false),
        ("anna@", false)
    ])
    func ungueltigeAdressen(_ input: String, _ expected: Bool) {
        #expect(EmailValidator.isValid(input) == expected)
    }
}

Die Annotation @Suite gruppiert verwandte Tests und erlaubt gemeinsame Traits (siehe nächster Abschnitt). Im Test-Navigator erscheint jedes Argument als eigene Zeile, sodass du gezielt einzelne Fälle erneut laufen lassen kannst. Bei zwei Argument-Sequenzen entsteht standardmäßig das Kreuzprodukt – nutze zip(), wenn du die Paare 1:1 koppeln möchtest. Für die offiziellen Details konsultiere die Apple-Dokumentation zu Swift Testing.

Traits, Tags und bedingte Tests

Traits sind das Metadaten-System von Swift Testing. Sie ersetzen unter anderem XCTSkip, XCTExpectFailure und das Setzen von Test-Plan-Konfigurationen. Die wichtigsten Traits aus der Praxis:

• .disabled("Grund") – deaktiviert den Test inklusive Begründung im Report.
• .enabled(if:) – führt den Test nur aus, wenn die Bedingung wahr ist (z. B. #available-Check oder Feature-Flag).
• .tags(.integration) – kennzeichnet Tests für Filterung in der CI.
• .bug("PROJ-123") – verlinkt den Test mit einem Issue-Tracker-Eintrag.
• .timeLimit(.minutes(1)) – setzt ein hartes Timeout.
• .serialized – erzwingt sequenzielle Ausführung der Tests in dieser Suite.

extension Tag {
    @Tag static var integration: Self
    @Tag static var slow: Self
}

@Suite("Datenbank-Schicht", .tags(.integration), .serialized)
struct DatabaseTests {
    @Test(.timeLimit(.seconds(5)))
    func migrationLaeuftDurch() async throws { /* ... */ }
}

Tags lassen sich in Xcode 26 direkt im Test-Plan filtern oder per Kommandozeile via --filter übergeben, was den klassischen Workaround mit Test-Plänen pro CI-Job überflüssig macht.

Parallelisierung in Swift Testing konfigurieren

Swift Testing führt Tests standardmäßig parallel im selben Prozess aus, ein scharfer Bruch mit XCTest, wo Parallelisierung optional und prozessbasiert war. Das senkt die Laufzeit dramatisch, deckt aber auch versteckte Abhängigkeiten zwischen Tests gnadenlos auf. Bei meinem letzten Projekt habe ich genau hier zwei Tage verloren: Ein Repository-Mock hielt eine statische Cache-Liste, und plötzlich schlugen sechs Tests sporadisch fehl, sobald die Suite parallel lief. Wer mit Singletons, gemeinsamen Mocks oder File-System-Zustand arbeitet, sollte vor der Migration eine ehrliche Bestandsaufnahme machen.

Für gemeinsamen Setup-Code nutzt du den Init der Suite und – seit Xcode 26 stabil – die Confirmation-API für asynchrone Erwartungen:

@Test func websocketSendetHeartbeat() async throws {
    await confirmation("Heartbeat empfangen", expectedCount: 3) { confirm in
        let socket = WebSocket()
        socket.onHeartbeat = { confirm() }
        try await socket.connect()
        try await Task.sleep(for: .seconds(3))
    }
}

Die Confirmation-API ersetzt XCTestExpectation und ist robuster gegenüber Race-Conditions, weil sie an die strukturierte Concurrency gebunden ist. Eine vertiefte Behandlung asynchroner Edge-Cases findest du in unserem Artikel zur Observable-Macro-Integration in UIKit, da viele Test-Szenarien dort identische Synchronisationsfragen aufwerfen.

Schritt-für-Schritt-Migration von XCTest

So, jetzt der praktische Teil. Eine pragmatische Migration läuft in fünf Schritten ab, und die Reihenfolge ist wichtig, weil jeder Schritt isoliert getestet werden kann und du jederzeit zurückrollen kannst.

1. Xcode-26-Toolchain sicherstellen. Prüfe per xcodebuild -version, dass mindestens Xcode 16 (Empfehlung: 26) installiert ist. Für Swift-Package-Manager-Projekte setzt du // swift-tools-version: 6.0 oder höher.
2. Neues Test-Target erstellen. Lege ein zweites Test-Target an oder ergänze das bestehende. Beide Frameworks laufen friedlich im selben Target – der Test-Runner erkennt sie an den Macros.
3. Eine Suite konvertieren. Wähle eine isolierte XCTest-Klasse ohne UI-Abhängigkeit. Ersetze import XCTest durch import Testing, die Klasse durch struct, jeden Test-Präfix durch @Test und jeden XCTAssert*-Aufruf durch #expect.
4. Setup/Teardown übertragen. setUp() wandert in den init der Suite, tearDown() in deinit. Asynchrone Variante: init() async throws ist seit Xcode 16 erlaubt.
5. Parametrisierung nutzen. Wo deine alten Tests Schleifen oder Helper-Funktionen verwendet haben, ersetze sie durch arguments: – das reduziert die Zeilenzahl typischerweise um 30–50 %.

Konkretes Vorher/Nachher:

// Vorher: XCTest
import XCTest
@testable import App

final class CartTests: XCTestCase {
    var cart: Cart!

    override func setUp() {
        super.setUp()
        cart = Cart()
    }

    func testAddItemIncreasesCount() {
        cart.add(Item(name: "Buch", price: 20))
        XCTAssertEqual(cart.count, 1)
        XCTAssertEqual(cart.total, 20)
    }
}

// Nachher: Swift Testing
import Testing
@testable import App

struct CartTests {
    let cart = Cart()

    @Test func addItemIncreasesCount() {
        cart.add(Item(name: "Buch", price: 20))
        #expect(cart.count == 1)
        #expect(cart.total == 20)
    }
}

Die offizielle Migrations-Anleitung mit allen Mapping-Tabellen findest du in der Swift-Testing-Dokumentation auf GitHub.

Swift Testing in CI: xcodebuild und swift test

Auf der Kommandozeile gibt es zwei Pfade. Für App-Projekte:

xcodebuild test \
  -scheme MyApp \
  -destination "platform=iOS Simulator,name=iPhone 16 Pro" \
  -only-testing:MyAppTests/CartTests

Für Swift Packages reicht swift test, optional mit --filter:

swift test --filter EmailValidatorTests
swift test --parallel  # standardmäßig aktiv ab swift-tools 6.0

Beide Befehle erzeugen ein .xcresult-Bundle, das in Xcode 26 mit erweitertem Issue-Detail geöffnet werden kann. Für GitHub Actions empfiehlt sich der offizielle swift-actions/setup-swift-Workflow plus ein Test-Plan, der nur Tests mit dem Tag .smoke auf Pull-Requests laufen lässt und volle Suites nachts. In zwei Teams hat diese Trennung die CI-Rechnung etwa halbiert (und nebenbei den PR-Feedback-Loop unter drei Minuten gedrückt).

Wann XCTest bleiben muss

Trotz aller Vorteile gibt es klare Fälle, in denen XCTest die richtige – und oft einzige – Wahl ist:

• UI-Tests: XCUIApplication, XCUIElementQuery und alle UI-Recording-Features bleiben XCTest-exklusiv. Swift Testing zielt bewusst nicht auf End-to-End-UI-Automatisierung.
• Performance-Tests: Die measure { ... }-API mit Baseline-Vergleich und Metric-Auswahl ist nicht in Swift Testing portiert.
• Snapshot-Bibliotheken: Viele etablierte Snapshot-Tools (z. B. PointFrees swift-snapshot-testing) integrieren bislang primär mit XCTest. Eine Swift-Testing-Bridge ist in vielen Bibliotheken erst experimentell.
• Legacy-Objective-C-Code: Wenn deine Test-Suite ObjC-Klassen testet, die XCTestCase erweitern, gibt es keinen Migrations-Pfad.

Die gute Nachricht: Du musst dich nicht entscheiden. Beide Frameworks koexistieren ohne Konflikt im selben Target, und Xcode 26 zeigt ihre Ergebnisse vereint im Test-Navigator. Die Migration läuft also iterativ – Suite für Suite – und niemand zwingt dich zu einem Big Bang.

Häufig gestellte Fragen

Soll ich von XCTest zu Swift Testing migrieren?

Für neue Tests ja – sie sind kürzer, parallel und besser lesbar. Bestehende XCTest-Suiten kannst du belassen; beide Frameworks koexistieren im selben Target. Plane Migrationen für Suiten, die du ohnehin refaktorierst.

Kann man XCTest und Swift Testing zusammen verwenden?

Ja. Du kannst beide Frameworks im selben Test-Target nutzen. Der Test-Runner führt sie nebeneinander aus, und Xcode 26 zeigt die Ergebnisse vereint im Test-Navigator und im .xcresult-Bundle.

Unterstützt Swift Testing UI-Tests?

Nein. XCUIApplication und das gesamte UI-Test-Toolkit bleiben XCTest-exklusiv. Für End-to-End-UI-Automatisierung musst du weiterhin XCTest verwenden – idealerweise in einem separaten UI-Test-Target.

Wie führe ich Swift Testing in der Kommandozeile aus?

Für App-Projekte nutzt du xcodebuild test mit dem passenden Scheme und Destination. Für Swift Packages reicht swift test, optional mit --filter NameDerSuite, um nur bestimmte Tests laufen zu lassen.

Welche Xcode-Version brauche ich für Swift Testing?

Mindestens Xcode 16. Empfohlen ist Xcode 26, weil dort die Tooling-Integration (Issue-Navigator, Inline-Werte aus #expect, Confirmation-API) vollständig ausgereift ist.