Symptom: Der Testlauf ist grün, obwohl eine erwartete Assertion offenbar nicht greift – oder die Ausgabe enthält eine neue Warnung.

Schnellste Lösung: Swift 6.4 unterstützt die schrittweise Zusammenarbeit von XCTest und Swift Testing, macht ihre APIs aber nicht pauschal austauschbar. Ermitteln Sie zuerst, welcher Test eine Assertion des anderen Frameworks aufruft; prüfen Sie anschließend Toolchain, swift-tools-version und Interop-Modus, bevor Sie Tests umschreiben. Die Unterstützung ist in den Versionshinweisen zu Swift 6.4 beschrieben.

Dieser Leitfaden richtet sich an Studierende, die ältere XCTest-Kursprojekte zusammen mit neuen Swift-Testing-Tests ausführen und unerwartete Berichte erhalten.
Auch Einsteiger, die eine Swift-Toolchain oder die Package-Konfiguration aktualisieren, können damit einschätzen, ob eine Modusänderung überhaupt nötig ist.
Wer seine Kursabgabe in Xcode prüft, findet hier eine Abgrenzung zwischen Assertion-Problem, nicht ausgeführtem Test und Build-Fehler.

Symptome zuerst einordnen

Ein ungewöhnlicher Testlauf ist nicht automatisch ein Fehler in der Interoperabilität. Notieren Sie vor Änderungen, was tatsächlich zu sehen ist: ein grüner Lauf trotz fraglicher Assertion, eine Warnung, ein roter fehlgeschlagener Test oder gar kein ausgeführter Test. Diese Fälle führen zu unterschiedlichen Prüfungen.

Swift Testing und XCTest dürfen in einem Projekt nebeneinander vorkommen. Swift 6.4 erweitert die Möglichkeiten, Assertions des jeweils anderen Frameworks zu verwenden. Daraus folgt aber nicht, dass Testdeklarationen, Lebenszyklus, Ergebnisdarstellung und jede API zwischen den Frameworks identisch funktionieren. Die offizielle Migrationsdokumentation zu XCTest und Swift Testing beschreibt die Grenzen und den vorgesehenen Wechsel.

Beobachtung im Bericht Erste Prüfung Noch nicht tun
Test ist grün, obwohl eine XCTAssert-Prüfung fehlschlagen sollte Aufrufstelle und Interop-Modus prüfen; den vollständigen Testbericht öffnen Die Hilfsfunktion nicht sofort durch eine andere Assertion ersetzen
Warnung oder Hinweis, Test läuft aber Toolchain, Package-Version und betroffenen Test festhalten Nicht allein wegen des Warnungstexts alle alten Tests modernisieren
Test ist rot Feststellen, ob eine Assertion, ein Setup-Schritt oder der Build scheitert Den Fehler nicht ohne Bericht dem Framework-Mix zuschreiben
Test erscheint gar nicht im Lauf Ausgewähltes Testziel und Testauswahl kontrollieren Nicht den Interop-Modus ändern, solange der Test nicht ausgeführt wird

Die Tabelle dient der ersten Sortierung, nicht als Diagnose aus der Ferne. Aussagekräftig sind der konkrete Test, seine Aufrufstelle und die vollständige Ausgabe. Wenn der Bericht nur eine zusammengefasste Meldung zeigt, öffnen Sie den betroffenen Testeintrag und prüfen Sie, ob dort eine Assertion, eine Warnung oder ein Ausführungsproblem genannt wird. Hinweise zur Anzeige von Testergebnissen finden Sie in der Dokumentation zum Ausführen und Interpretieren von Tests.

Die Aufrufstelle einer Assertion verfolgen

Beginnen Sie im Test, der die unerwartete Ausgabe erzeugt. Fragen Sie nicht nur, welche Assertion im Projekt steht, sondern auch, welches Framework den Test deklariert und ob eine Hilfsfunktion die Assertion aufruft.

Ein typischer Lernprojekt-Fall sieht so aus: Ein älterer XCTest-Test verwendet eine wiederverwendbare Prüf-Funktion. Ein neuer Test im Stil von Swift Testing ruft dieselbe Funktion auf. Der Test kann im Editor sauber aussehen und trotzdem einen anderen Bericht erzeugen als erwartet, weil die Assertion innerhalb der Hilfsfunktion aus dem jeweils anderen Framework stammt. Suchen Sie deshalb nach dem Aufruf und öffnen Sie die Funktionsdefinition.

Gehen Sie dabei in dieser Reihenfolge vor:

  1. Testdeklaration bestimmen: Ist der Test als XCTest-Methode in einer XCTestCase-Unterklasse angelegt oder als Swift-Testing-Test markiert?
  2. Assertion identifizieren: Wird XCTAssert… aufgerufen, oder enthält der Test eine native Swift-Testing-Prüfung wie #expect?
  3. Hilfsfunktionen durchsuchen: Prüfen Sie, ob die Assertion nicht direkt im Test, sondern in einer gemeinsam verwendeten Funktion steht.
  4. Testziel kontrollieren: Stellen Sie sicher, dass der betroffene Quellcode zum tatsächlich gestarteten Testziel gehört.
  5. Bericht sichern: Halten Sie Meldung und betroffene Teststelle fest, bevor Sie Konfiguration oder Code ändern.

Für die Unterschiede zwischen XCTest und Swift Testing verweist die Migrationsdokumentation auf den schrittweisen Wechsel. Die Beschreibung der Interoperabilität im Swift-Evolution-Vorschlag ST-0021 erläutert außerdem, warum ein Aufruf über Framework-Grenzen hinweg gesondert behandelt werden muss.

Achtung: Eine Hilfsfunktion kann selbst keine Testmethode sein und dennoch den entscheidenden Assertion-Aufruf enthalten. Wenn nur die Testdeklaration geprüft wird, bleibt genau diese Fehlerquelle leicht unentdeckt.

Toolchain und Package-Version festhalten

Die Toolchain ist die konkrete Swift-Werkzeugkette, die den Build und die Tests ausführt. Die swift-tools-version im Package-Manifest ist dagegen eine Versionsangabe, mit der ein Swift-Package seine erwartete Werkzeugunterstützung festlegt. Vereinfacht gesagt: Die Toolchain ist das verwendete Werkzeug, der Manifest-Eintrag eine Regel dafür, welche Werkzeugversion das Package voraussetzt. Die Dokumentation zu swift-tools-version erklärt diese Angabe.

Das ist bei einer Warnung nach einem Upgrade wichtig: Das installierte Swift und die im Package deklarierte Version müssen nicht dieselbe Zahl tragen. Außerdem kann die verwendete Testumgebung eine andere Toolchain einsetzen als die, mit der das Projekt zuvor lokal geöffnet wurde. Ein Upgrade allein beweist daher nicht, dass eine Assertion geändert werden muss.

Notieren Sie für einen reproduzierbaren Vergleich:

  • Swift-Version beziehungsweise verwendete Toolchain,
  • den Wert von swift-tools-version,
  • das gestartete Testziel,
  • die konkrete Assertion und ihren Aufrufort,
  • den vollständigen Testbericht,
  • den für den Lauf geltenden Interop-Modus.

Wenn ein Projekt über den Swift Package Manager getestet wird, starten Sie den bekannten Testlauf erneut, ohne gleichzeitig Code und Konfiguration zu verändern. So lässt sich feststellen, ob die Abweichung mit dem Framework-Aufruf oder mit einer geänderten Laufumgebung zusammenhängt. Bei einem Xcode-Projekt gilt dasselbe Prinzip: Erst Testziel und Bericht sichern, dann eine einzelne Ursache untersuchen. Die Übersicht zu Tests in Xcode beschreibt das Ausführen und Organisieren von Tests.

Den Interop-Modus passend wählen

Ein Interop-Modus steuert, wie die Zusammenarbeit zwischen XCTest und Swift Testing für den betreffenden Testlauf behandelt beziehungsweise gemeldet wird. Die dokumentierten Bezeichnungen umfassen none, limited, complete und strict. Prüfen Sie die Beschreibung des jeweiligen Modus in der offiziellen Migrationsanleitung und im Vorschlag ST-0021, bevor Sie aus einem Modusnamen auf die konkrete Wirkung schließen.

Der Modus kann beeinflussen, wie ein Testlauf ein Problem über die Framework-Grenze hinweg behandelt oder sichtbar macht. Er ist aber keine Reparatur für eine falsch ausgewählte Test-Suite, einen fehlerhaften Build oder eine Assertion, die im betreffenden Test gar nicht ausgeführt wird. Eine Änderung kann außerdem die Meldung verschärfen oder weniger streng erscheinen lassen, ohne die Ursache im Testcode zu beseitigen.

Gehen Sie daher nicht nach dem Muster „rote Ausgabe entfernen“ vor. Halten Sie den bisherigen Modus fest, ändern Sie – falls die Dokumentation und der Bericht es rechtfertigen – nur diese Einstellung und führen Sie anschließend dieselben Tests erneut aus. Die Umgebungsvariable SWIFT_TESTING_XCTEST_INTEROP_MODE wird in der offiziellen Beschreibung im Zusammenhang mit der Steuerung des Interop-Modus behandelt. Verifizieren Sie den genauen Namen und die zulässigen Werte für Ihre Toolchain in der Dokumentation, statt eine ähnliche Variable aus einem Forum zu übernehmen.

Entscheidungszweige für den nächsten Schritt:

  • Wenn der betroffene Test gar nicht im Bericht auftaucht, prüfen Sie zuerst Testziel, Auswahl und Build. Ändern Sie den Interop-Modus erst, wenn der Test tatsächlich ausgeführt wird.
  • Wenn eine XCTest-Assertion aus einem Swift-Testing-Test oder umgekehrt aufgerufen wird, vergleichen Sie Aufrufstelle und geltenden Modus mit der offiziellen Interop-Beschreibung.
  • Wenn eine Warnung erscheint, der Test aber nachvollziehbar läuft, sichern Sie zunächst Bericht und Konfiguration. Modernisieren Sie nur dann gezielt, wenn die dokumentierte Bedeutung der Warnung den konkreten Fall betrifft.
  • Wenn der Test nach einer Modusänderung anders bewertet wird, stellen Sie den vorherigen Zustand wieder her, sofern Sie die Änderung nicht anhand der Dokumentation begründen können.
  • Wenn der Build bereits vor dem Test scheitert, behandeln Sie den Build-Fehler getrennt; eine Assertion-Interoperabilität kann einen fehlgeschlagenen Build nicht erklären.

Mischtests von anderen Fehlern abgrenzen

Ein fehlgeschlagener Test, ein übersprungener Test und ein nicht gestartetes Testziel sind nicht dasselbe. Ebenso ist eine Meldung beim Kompilieren nicht automatisch ein fehlgeschlagener Assertion-Aufruf. Im Bericht sollte zu erkennen sein, ob ein Test ausgeführt wurde und an welcher Stelle der Lauf endete. Prüfen Sie das, bevor Sie Projektdateien oder Testcode verändern.

Auch die Unterscheidung zwischen Unit- und UI-Tests ist hier nur insofern wichtig, als unterschiedliche Testziele und Startbedingungen beteiligt sein können. Wenn ein Unit-Test fehlt, während ein anderes Ziel ausgeführt wurde, weist das zunächst auf die Testauswahl oder das Ziel hin, nicht auf die Interoperabilität der Assertions. Für den konkreten Fall genügt es, Ziel und Bericht miteinander abzugleichen.

Die folgende Prüfliste hält die Fehlersuche klein und nachvollziehbar:

  • [ ] Der betroffene Test ist im aktuellen Testbericht tatsächlich aufgeführt.
  • [ ] Das richtige Testziel wurde gestartet.
  • [ ] Die Testdeklaration ist als XCTest oder Swift Testing identifiziert.
  • [ ] Die genaue Assertion und gegebenenfalls die Hilfsfunktion sind bekannt.
  • [ ] Toolchain und swift-tools-version sind notiert.
  • [ ] Der geltende Interop-Modus ist festgestellt.
  • [ ] Build-Fehler, übersprungene Tests und Assertion-Fehler sind getrennt eingeordnet.

Fehlt ein Häkchen bei Testziel oder Testausführung, ist der nächste Schritt die Projekt- beziehungsweise Testauswahlprüfung. Fehlt es bei Assertion oder Modus, untersuchen Sie zuerst den Interop-Aufruf. Ändern Sie nicht mehrere dieser Punkte gleichzeitig: Sonst lässt sich nach dem nächsten Lauf nicht erkennen, welche Änderung den Bericht beeinflusst hat.

Ergebnisse mit einem kleinen Testpaar bestätigen

Eine Korrektur ist erst dann belastbar, wenn derselbe Testlauf sowohl einen erwarteten Erfolg als auch einen erwarteten Fehlschlag sinnvoll meldet. Erstellen Sie dafür in einem überschaubaren Testbereich eine positive Prüfung mit einer Bedingung, die erfüllt sein soll, und eine negative Prüfung mit einer Bedingung, die bewusst nicht erfüllt ist. Verwenden Sie dabei den Framework-Mix, der den ursprünglichen Fehler ausgelöst hat.

Führen Sie den Vergleich kontrolliert durch:

  1. Bericht und Konfiguration vor der Änderung sichern.
  2. Nur die begründete Änderung an Assertion, Aufrufstelle oder Interop-Modus vornehmen.
  3. Beide Prüfungen mit demselben Testziel erneut ausführen.
  4. Im Bericht kontrollieren, ob der erwartete Erfolg und der erwartete Fehlschlag getrennt erkennbar sind.
  5. Toolchain, swift-tools-version, Modus und Aufrufstelle zum Ergebnis notieren.

Wenn beide Fälle nachvollziehbar berichtet werden und keine unerklärte Warnung mehr auftritt, ist die Änderung für diesen Testfall bestätigt. Bleibt das Ergebnis unklar, gehen Sie auf den zuvor gesicherten Zustand zurück und prüfen Sie den offiziellen Modus für Ihre konkrete Toolchain erneut. Behaupten Sie nicht, dass ein einzelner erfolgreicher Lauf alle Tests des Projekts abdeckt.

Hinweis für Kursabgaben: Bewahren Sie nur die Informationen auf, die zur Reproduktion nötig sind. Vor dem Teilen eines Projekts oder Testberichts sollten personenbezogene Daten, Zugangsdaten und nicht freigegebener Quellcode entfernt werden. Bei einer entfernten Entwicklungsumgebung ist zusätzlich zu prüfen, welche Daten übertragen und gespeichert werden.

Wenn die lokale Mac-Umgebung der Engpass ist

Bleibt der Fehler trotz korrektem Testziel und dokumentiertem Modus unklar, kann die Ursache in einer nicht verfügbaren oder abweichenden Xcode-Umgebung liegen. Für eine Apple-Plattform-Abgabe lässt sich ein Projekt ohne laufendes Xcode nicht vollständig so prüfen wie in einer passenden Mac-Entwicklungsumgebung. Das macht einen gemischten Framework-Aufruf nicht automatisch zur Ursache, verhindert aber eine verlässliche Wiederholung des Testlaufs.

Wer regelmäßig an einem eigenen Mac arbeitet und stabile, dauerhafte Nutzung benötigt, sollte Anschaffung und lokale Einrichtung mit einer temporären Umgebung vergleichen. Wer nur ein Kursprojekt prüfen oder einen Fehler reproduzieren muss, kann dagegen zunächst die Möglichkeiten für den Mac-Zugriff ansehen und die Bedingungen mit dem eigenen Kursbedarf abgleichen. Vor einer Buchung sollten Laufzeit, Zugangsweg und Datenschutzanforderungen geprüft werden; sensible Kursdaten gehören nicht ohne Freigabe auf ein fremdverwaltetes System. Informationen zu den Tarifoptionen helfen dabei, den zeitweisen Zugriff gegen die eigene Nutzung abzuwägen.

Wenn die Ursache also tatsächlich darin liegt, dass kein ausführbares Xcode-Projekt auf einem Mac verfügbar ist, kann ein zeitweise gemieteter Mac von RUVCLOUD praktischer sein als ein unvollständiger Testlauf auf dem vorhandenen Rechner. Eine Remote-Umgebung ersetzt jedoch keinen eigenen Mac, wenn dauerhaft hohe Nutzung oder physische Anschlüsse erforderlich sind. Für eine einmalige Kursprüfung sollte zuerst die nötige Umgebung geklärt und danach die passende Bestellmöglichkeit geprüft werden.