Söz dizimi ve okunabilirlik: #expect/#require vs XCTAssert
Swift Testing'in #expect makrosu Swift ifadelerini ve operatörlerini doğrudan kullanır; test başarısız olduğunda ifadenin içindeki değerleri otomatik yakalayıp okunur bir hata mesajı üretir — Apple'ın kendi örneğinde bir karşılaştırma başarısız olduğunda 'Expectation failed: (greeting → "Hello, world!") == "Hello"' şeklinde otomatik değer raporlanır. XCTest'te bunun karşılığı yok: Boolean, Nil/Non-Nil, Equality, Comparable, Error ve NSException için ayrı assertion aileleri var (XCTAssertEqual, XCTAssertTrue, XCTAssertNil...), her biri kendi imzasıyla ezberlenmesi gereken ayrı bir fonksiyon. Pratikte bu, Swift Testing testlerinin daha az kod ve daha az 'hangi assertion'ı kullanmalıyım' sürtünmesiyle yazılması, hata mesajlarının ise ekstra açıklama satırı eklemeden daha bilgilendirici çıkması anlamına geliyor. #require ise başarısız olduğunda testi doğrudan durduran, ön koşul niteliğindeki kontroller için kullanılıyor.
Parametreli test desteği
Swift Testing'de parametreli testler birinci sınıf bir özellik: @Test(arguments:) ile aynı testi bir değer dizisi üzerinde çalıştırabiliyorsun; tek koleksiyon, iki koleksiyonun zip'i veya CustomTestArgumentEncodable protokolüyle özel argüman kodlaması destekleniyor. Bu, 'aynı mantığı beş farklı girdiyle test et' senaryosunda beş ayrı test fonksiyonu yazmak yerine tek bir @Test bloğu yazmak demek — yukarıdaki kod örneğindeki kupon-indirim testi bunun tipik bir gösterimi. XCTest'in resmi API yüzeyinde eşdeğer bir yapı yok; geliştiriciler pratikte bir dizi üzerinde döngü kurup her adımda XCTAssert çağırarak bunu taklit ediyor, ama bu yaklaşımda tek bir vakanın başarısızlığı döngünün geri kalanını maskeleyebiliyor ve hangi girdinin başarısız olduğunu ayırt etmek Swift Testing'deki kadar net değil.
Paralel çalıştırma modeli ve izolasyon
Swift Testing testleri varsayılan olarak birbirine paralel çalışır; bu paralellik Swift'in task group'ları üzerinden, genelde aynı süreç içinde (in-process) sağlanıyor ve eşzamanlı çalışan test sayısı Swift runtime tarafından kontrol ediliyor. Bunu istemediğin suite veya test fonksiyonu için .serialized trait'iyle kapatabiliyor, ya da 'swift test --no-parallel' bayrağıyla tüm süiti global olarak sıralı çalıştırabiliyorsun. XCTest'te paralellik geleneksel olarak test hedefi/şema seviyesinde Xcode tarafından, ayrı simülatör klonları veya süreçler üzerinden yönetiliyor — fonksiyon seviyesinde in-process task-group paralelliği XCTest'in API yüzeyinde yok. Pratik sonucu: Swift Testing'e geçerken DB fixture, singleton veya mock dosya sistemi gibi paylaşılan durumu olan eski testler, varsayılan paralellikte race condition'a düşebilir — bu en sık karşılaşılan göç tuzaklarından biri. İki framework için kaynaklı, yayımlanmış bir hız benchmark'ı bulunmadığından performans puanları eşit verildi; fark ölçüm değil, model farkıdır.
UI testi kapsamı: XCUITest hâlâ gerekli mi
Kesin cevap evet. Apple'ın kendi dokümantasyonu şunu birebir söylüyor: 'A test target can contain tests using both Swift Testing and XCTest, however don't mix API from the two frameworks in the same test. Continue to use XCTest for user interface tests and Performance Tests.' Swift Testing'in @Test makrosuyla XCUIApplication veya XCUIElement kontrol edilemiyor; UI otomasyon API'sinin Swift Testing tarafında bir karşılığı yok. Aynı şekilde XCTMetric ile yapılan Performance Testleri de XCTest'e özgü kalıyor. Bu yüzden 2026 itibarıyla gerçekçi kurulum, aynı hedefte iki framework'ü bir arada tutmak: birim/entegrasyon testleri Swift Testing'de, UI ve performans testleri XCTest'te.
Aynı hedefte birlikte çalışabilirlik
Apple'ın resmi göç dokümanı açık: 'A single source file can contain tests written with XCTest as well as other tests written with the testing library.' Yani iki framework yalnızca aynı hedefte değil, aynı dosyada bile yan yana durabiliyor — tek kısıt aynı test fonksiyonunun içinde iki framework'ün API'lerini karıştırmamak. Bu birlikte çalışabilirliğin derecesini SWIFT_TESTING_XCTEST_INTEROP_MODE ortam değişkeni belirliyor (none/limited/complete/strict); varsayılan mod kullanılan toolchain ve swift-tools-version kombinasyonuna göre otomatik seçiliyor. Swift 6.4 (15 Eylül 2026) ile bu interop'a önemli bir iyileştirme geldi: artık bir XCTest dosyasındaki XCTAssert başarısızlığı Swift Testing tarafında da issue olarak raporlanabiliyor ve tersi de çalışıyor — önceden bu çapraz-framework sinyali sessizce kayboluyordu.
Swift Concurrency ve async test ergonomisi
Swift Testing'in resmi özellik listesinde ilk sırada 'Integrate seamlessly with Swift concurrency' yer alıyor: test fonksiyonları doğrudan async throws olabiliyor ve kütüphanenin paralel çalıştırma modeli zaten Swift'in task group'larına dayanıyor — yani concurrency, kütüphanenin tasarım ekseninin merkezinde. XCTest'te async destek var ama ayrı bir alt-başlık olarak dokümante edilmiş: 'Asynchronous Tests and Expectations' — XCTestExpectation ve wait(for:) tabanlı bir model, XCTest'in temel senkron test-fonksiyonu tasarımına sonradan eklenmiş. Pratikte XCTest'te de 'async func test...() async throws' yazılabiliyor, ama expectation tabanlı eski API'lerle karışık kod tabanlarında iki paradigmanın bir arada yönetilmesi gerekiyor.
CI raporlama, xcresult ve hata izlenebilirliği
Swift Testing'de bug(_:id:) trait'i ile FB-önekli tanımlayıcılar doğrudan Apple Feedback Assistant'a bağlanıyor; bu, framework kaynaklı hataları izlemeyi kolaylaştıran yerleşik bir mekanizma. Strict interop modunda XCTest tarafındaki çapraz-framework issue'lar fatalError() ile sonuçlanarak CI'de sert bir kapı oluşturabiliyor. Test tekrarı Swift Testing'de ilk sürümden beri var; Swift 6.4'ün getirdiği, tekrarı tüm test hedefi yerine yalnızca koşulu sağlayan test-case'e indirmek ve 'swift test'e --maximum-repetitions ile --repeat-until bayraklarını eklemek oldu (ST-0024). Aynı öneri, başarısız testi tekrarlamanın XCTest'te zaten var olan bir davranış olduğunu birebir söylüyor: 'This also does not match the behavior of XCTest, which repeats failing test methods instead of all tests within an XCTestCase or the entire test target.' Yani flaky testle başa çıkma ikisinde de mümkün; fark granülerlikte ve komut satırı ergonomisinde. XCTest ve Swift Testing, sonuçlarını aynı xcodebuild/xcresult boru hattı üzerinden raporluyor — yani Xcode Test Report ve CI entegrasyonu iki framework için de ortak altyapıyı paylaşıyor, ayrı bir rapor formatı öğrenmen gerekmiyor.