Swift Testing vs XCTest Karşılaştırması

Apple'ın yeni açık kaynak test kütüphanesi — makro tabanlı, Swift Concurrency'ye doğal entegre

VS
XCTest

~13 yıllık, savaş testi geçirmiş framework — UI ve Performance testlerinin tek adresi

15 dk okumaiOS

Hızlı Karar

Net eğilim var ama 'topluca göç' gereksiz risk. Yeni birim/entegrasyon testlerini Swift Testing ile yaz — daha az kod, otomatik değer yakalama, yerleşik parametreli test ve paralellik kazandırıyor. UI/Performance testlerini XCTest'te bırak; Apple dokümantasyonu bunu istiyor. İki framework aynı hedefte durabildiği ve Swift 6.4 çapraz-raporlama getirdiği için topluca göç gereksiz — dosya dosya ilerle.

Swift TestingXCTest
Tam sonucu oku

Puan Karşılaştırması

Grafik yükleniyor...

Detaylı Puanlama

Detaylı Puanlama: Swift Testing ve XCTest — kategori bazında 10 üzerinden puanlar
KategoriSwift TestingXCTest
Performans
8/10
8/10
Öğrenme Kolaylığı
7/10
6/10
Ekosistem
6/10
8/10
Topluluk
6/10
8/10
İş Pazarı
5/10
7/10
Gelecek
9/10
6/10

Artıları & Eksileri

Swift Testing

Artıları

  • #expect ve #require makroları ile tek satırda otomatik değer yakalama, ayrı assertion ailesi ezberlemene gerek yok
  • Yerleşik parametreli test desteği (@Test(arguments:)) — döngü yazmadan tek testte çoklu senaryo
  • Varsayılan olarak paralel çalışır; task group tabanlı in-process paralellik ile daha hızlı test süiti
  • async throws test fonksiyonları doğal — Swift Concurrency ile sürtünmesiz entegrasyon
  • Test iptali (Test.cancel()), uyarı-seviyeli issue kaydı ve görsel/Transferable ek desteği (Swift 6.3-6.4)
  • Apple platformları dışında Linux ve Windows'ta da resmi toolchain ile çalışıyor
  • Açık kaynak (Apache 2.0) — GitHub'da aktif geliştirme ve topluluk katkısına açık
  • FB-önekli bug tanımlayıcıları doğrudan Apple Feedback Assistant'a bağlanıyor

Eksileri

  • UI otomasyonu (XCUIApplication/XCUIElement) ve Performance Testleri desteklemiyor — bunlar için XCTest şart
  • Xcode 16 / Swift 6 araç zinciri altı projelerde kullanılamıyor, eski Xcode sürümlerinde yok
  • Daha genç ekosistem — üçüncü parti kütüphane ve StackOverflow cevap havuzu XCTest kadar derin değil
  • #expect içinde throw edilen hata sonraki expectation'ları sessizce durdurabiliyor, #require veya do/catch disiplinini gerektiriyor
  • Varsayılan paralel çalıştırma, paylaşılan durum (DB fixture, singleton) içeren eski test kodlarında race condition'ı açığa çıkarabiliyor

En Uygun

Yeni açılan iOS/macOS/Linux birim ve entegrasyon testleriÇok sayıda girdi kombinasyonu gerektiren parametreli test senaryolarıSwift Concurrency (async/await) ağırlıklı kod tabanlarıHızlı paralel test süiti isteyen büyüyen projelerCross-platform Swift paketleri (Linux/Windows CI dahil)

XCTest

Artıları

  • Xcode 5'ten (2013) beri Apple'ın resmi test framework'ü — kurumsal projelerde kanıtlanmış stabilite
  • XCUITest ile UI otomasyonu ve Performance Testleri yalnızca XCTest'te mevcut
  • ~13 yıllık StackOverflow, blog ve kitap içeriğiyle en derin bilgi tabanı
  • Xcode'un test raporlama (xcresult), Test Plan ve CI entegrasyonuyla tam kaynaşmış
  • Objective-C dahil karma kod tabanlarında hâlâ zorunlu tek seçenek
  • Büyük ekiplerde herkesin bildiği ortak bir sözdizimi — onboarding maliyeti düşük
  • Ayrı bir assertion ailesi her senaryo için (Boolean/Nil/Equality/Comparable/Error) net ve öngörülebilir
  • Performans testleri için XCTMetric ile ölçüm altyapısı yerleşik

Eksileri

  • Parametreli test için yerleşik API yok — döngü veya yardımcı fonksiyonla taklit etmek gerekiyor
  • XCTAssert* fonksiyon ailesi verbose; Swift Testing'deki gibi otomatik değer yakalama yok
  • Test-fonksiyonu seviyesinde in-process task-group paralelliği yok; paralellik simülatör/süreç seviyesinde yönetiliyor
  • Async destek sonradan eklenmiş (XCTestExpectation/wait(for:)) — Swift Concurrency ile Swift Testing kadar doğal değil
  • Apple'ın WWDC24'teki yönlendirmesi XCTest'i UI otomasyonu, performans testleri ve yalnızca Objective-C ile yazılabilen testlerle sınırlıyor — yeni birim testi ergonomisi Swift Testing'de gelişiyor
  • Objective-C kökenli API yüzeyi, yeni Swift geliştiricilerine daha ağır geliyor

En Uygun

XCUITest ile UI otomasyon testleriXCTMetric tabanlı Performance TestleriObjective-C içeren veya eski Xcode sürümlerini destekleyen projelerUzun süredir çalışan büyük legacy test paketleriEkip genelinde ortak, olgun bir test sözleşmesi gereken kurumsal projeler

Kod Karşılaştırması

Swift Testing
// Swift Testing — parametreli async birim testi
import Testing
@testable import PaymentKit

@Suite("Fiyat hesaplama")
struct PriceCalculatorTests {

    @Test("Geçerli kupon kodlarıyla indirim doğru hesaplanır",
          arguments: [
              ("SAVE10", 100.0, 90.0),
              ("SAVE20", 100.0, 80.0),
              ("NONE", 100.0, 100.0)
          ])
    func discountIsApplied(code: String, base: Double, expected: Double) async throws {
        let calculator = PriceCalculator()
        let result = try await calculator.applyDiscount(code: code, to: base)
        #expect(result == expected, "\(code) için beklenen \(expected), gelen \(result)")
    }

    @Test("Geçersiz kupon hata fırlatır")
    func invalidCouponThrows() async throws {
        let calculator = PriceCalculator()
        await #expect(throws: CouponError.invalid) {
            try await calculator.applyDiscount(code: "XXX", to: 100.0)
        }
    }

    @Test("Sepet toplamı gereklidir", .disabled("Sepet servisi henüz taşınmadı"))
    func cartTotalRequired() async throws {
        let calculator = PriceCalculator()
        try #require(calculator.cartTotal > 0)
    }
}
XCTest
// XCTest — aynı senaryo (fiyat hesaplama) + UI testi
import XCTest
@testable import PaymentKit

final class PriceCalculatorTests: XCTestCase {
    var calculator: PriceCalculator!

    override func setUpWithError() throws {
        calculator = PriceCalculator()
    }

    func testDiscountIsAppliedForKnownCoupons() async throws {
        let cases: [(String, Double, Double)] = [
            ("SAVE10", 100.0, 90.0),
            ("SAVE20", 100.0, 80.0),
            ("NONE", 100.0, 100.0)
        ]
        for (code, base, expected) in cases {
            let result = try await calculator.applyDiscount(code: code, to: base)
            XCTAssertEqual(result, expected, "kupon: \(code)")
        }
    }

    // XCTAssertThrowsError senkrondur; async çağrıda do/catch + XCTFail kullan
    func testInvalidCouponThrows() async throws {
        do {
            _ = try await calculator.applyDiscount(code: "XXX", to: 100.0)
            XCTFail("hata bekleniyordu")
        } catch {
            XCTAssertEqual(error as? CouponError, .invalid)
        }
    }
}

// UI testi — yalnızca XCTest/XCUITest ile mümkün
final class CheckoutUITests: XCTestCase {
    func testApplyCouponButtonUpdatesTotal() throws {
        let app = XCUIApplication()
        app.launch()
        app.textFields["couponField"].tap()
        app.textFields["couponField"].typeText("SAVE10")
        app.buttons["applyCouponButton"].tap()
        XCTAssertEqual(app.staticTexts["totalLabel"].label, "$90.00")
    }
}

Sonuç

Net eğilim var ama 'topluca göç' gereksiz risk. Yeni birim/entegrasyon testlerini Swift Testing ile yaz — daha az kod, otomatik değer yakalama, yerleşik parametreli test ve paralellik kazandırıyor. UI/Performance testlerini XCTest'te bırak; Apple dokümantasyonu bunu istiyor. İki framework aynı hedefte durabildiği ve Swift 6.4 çapraz-raporlama getirdiği için topluca göç gereksiz — dosya dosya ilerle.

Ücretsiz Danışmanlık Al
SSS

Sıkça Sorulan Sorular

Hayır. Swift Testing yeni birim ve entegrasyon testleri için Apple'ın önerdiği varsayılan ama XCTest kaldırılmadı; XCUITest (UI otomasyonu) ve XCTMetric (performans testi) hâlâ yalnızca XCTest'te var. İkisi aynı hedefte, Swift 6.4'ten sonra çapraz-framework raporlamayla birlikte çalışabiliyor.

Giriş

Yeni bir iOS projesine başlarken test altyapısını hangi framework'le kuracağın önemli bir karar: Apple'ın 2024'te tanıttığı Swift Testing mi, yoksa Xcode 5'ten (2013) bu yana projelerin omurgasını oluşturan XCTest mi? Bu ikisini birbirinin rakibi gibi görme — 2026 itibarıyla resmi Apple dokümantasyonu aynı hedefte, hatta aynı dosyada bir arada kullanılabileceklerini açıkça söylüyor. Asıl soru 'hangisini seçmeliyim' değil, 'hangi iş için hangisini kullanmalıyım'. Bu sayfada söz dizimini, parametreli test desteğini, paralel çalıştırma modelini, UI testi kapsamını, birlikte çalışabilirliği, Swift Concurrency ergonomisini ve CI raporlamasını sekiz kriter üzerinden karşılaştırıyoruz. Swift 6.3 (24 Mart 2026) ve Swift 6.4 (15 Eylül 2026) ile gelen yenilikleri ve Xcode 27 final'i (14 Eylül 2026) hesaba katarak güncel, kanıta dayalı bir karar tablosu çıkarıyoruz.

Karşılaştırma Matrisi

Karşılaştırma Matrisi: Swift Testing / XCTest
ÖzellikSwift TestingXCTest
İlk yayın2024 (WWDC24)2013 (Xcode 5) (Öne çıkan)
LisansApache 2.0 (açık kaynak) (Öne çıkan)Kapalı, Xcode SDK parçası
Söz dizimi#expect/#require makroları, otomatik değer yakalama (Öne çıkan)XCTAssert* fonksiyon aileleri
Parametreli testYerleşik @Test(arguments:) (Öne çıkan)Yerleşik yok, döngüyle taklit
Varsayılan paralellikEvet, in-process task group (Öne çıkan)Hayır, süreç/simülatör seviyesinde
UI otomasyonu (XCUITest)DesteklemiyorYerleşik, tek seçenek (Öne çıkan)
Performance Testleri (XCTMetric)DesteklemiyorYerleşik (Öne çıkan)
Async/await entegrasyonuTasarımın merkezinde (Öne çıkan)Sonradan eklenmiş (XCTestExpectation)
Aynı hedefte birlikte çalışabilirlikEvet (Xcode 16'dan beri; Swift 6.4 çapraz issue raporlaması)Evet (Xcode 16'dan beri; Swift 6.4 çapraz issue raporlaması)
Minimum araç zinciriXcode 16 / Swift 6Herhangi bir Xcode sürümü (Öne çıkan)
Platform kapsamıApple platformları + Linux/WindowsApple platformları + Linux/Windows (swift-corelibs-xctest, Xcode 7 API alt kümesi; XCUITest yok)
Topluluk birikimi (yıl)~2 yıl~13 yıl (Öne çıkan)
Test iptali (Test.cancel())Var (Swift 6.3) (Öne çıkan)Yok
Başarısız testi tekrarlamaVar (test-case bazlı, Swift 6.4 + swift test bayrakları)Var (Xcode Test Plan tekrarları)

Derinlemesine İnceleme

Swift Testing

Genel Bakış

Swift Testing, Apple'ın WWDC 2024'te "Meet Swift Testing" oturumuyla tanıttığı, Xcode 16 ve sonrasıyla birlikte gelen açık kaynak (Apache 2.0) test kütüphanesi. Amaç, Swift'in makro sistemi ve Swift Concurrency'sinden yararlanarak XCTest'in Objective-C kökenli, fonksiyon-ailesi tabanlı assertion modelini modernize etmek. Testler varsayılan olarak paralel ve in-process çalışır, #expect/#require makroları ifadeyi ve değerlerini otomatik yakalayıp okunur hata mesajları üretir. Swift 6.3 (24 Mart 2026) test iptali, uyarı-seviyeli issue kaydı ve görsel ek desteğini getirdi; Swift 6.4 (15 Eylül 2026) ise XCTest ile çift yönlü çapraz-framework issue raporlamasını ekledi; test tekrarını da tüm hedef yerine yalnızca koşulu sağlayan test-case'e indirip swift test'e --maximum-repetitions/--repeat-until bayraklarını getirdi (ST-0024). Swift Testing, XCTest'in yerini almak için değil, onunla aynı hedefte ve hatta aynı dosyada bir arada çalışmak üzere tasarlandı; UI otomasyonu ve Performance Testleri kapsamı dışında.

Ekosistem

Paket yöneticisi
Swift Package Manager (SPM)
Geliştirme ortamı
Xcode 16 ve sonrasıVSCode + Swift extension
Popüler kütüphaneler
swift-testing (çekirdek, resmi)swift-snapshot-testing (kısmi Swift Testing desteği)XCTest-interop köprü kodları (proje-içi)

XCTest

Genel Bakış

XCTest, Apple'ın Xcode 5 ile (2013) tanıttığı, ~13 yıllık production geçmişine sahip resmi iOS/macOS test framework'ü. Objective-C kökenli, XCTAssert* fonksiyon aileleri (Boolean, Nil/Non-Nil, Equality, Comparable, Error) üzerine kurulu. XCUITest ile UI otomasyonu, XCTMetric ile Performance Testleri sağlıyor — bu iki alan Swift Testing'de karşılığı olmayan, Apple'ın "Continue to use XCTest for user interface tests and Performance Tests" diyerek doğrudan XCTest'e bıraktığı alanlar. Xcode 16+'da Swift Testing ile aynı hedefte, hatta aynı dosyada bir arada bulunabiliyor; Swift 6.4 (15 Eylül 2026) ile gelen çapraz-framework issue raporlaması sayesinde bir XCTest assertion'ının başarısızlığı artık Swift Testing tarafında da görünür. XCTest deprecate edilmedi; Apple bu iki alan için XCTest'i kullanmaya devam etmeni söylüyor, Objective-C zorunlu testler de XCTest'te kalıyor.

Ekosistem

Paket yöneticisi
Xcode SDK'sının parçası (ayrı paket yönetimi gerekmez)
Geliştirme ortamı
Xcode 16 ve sonrası (Test Navigator + Test Plans)
Popüler kütüphaneler
XCUITest (built-in, UI otomasyonu)XCTMetric (built-in, performans ölçümü)Quick/Nimble (BDD katmanı, XCTest üzerine)ViewInspector (SwiftUI view test yardımcı kütüphanesi)

Teknik Analiz

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.

Hangi Senaryoda Hangisi

Sıfırdan yeni bir iOS/macOS uygulaması başlatıyorsun

Öneri: Birim ve entegrasyon testlerini Swift Testing ile yaz; UI akışları için ayrı bir XCUITest hedefi ekle.

Apple'ın güncel yönü bu; daha az kod, yerleşik parametreli test ve varsayılan paralellik yeni kod tabanında ek risk taşımaz.

Büyük, olgun bir XCTest paketin var ve göç bütçesi kısıtlı

Öneri: Mevcut testleri olduğu gibi bırak, yalnızca yeni yazılan testleri Swift Testing'de yaz.

Apple'ın resmi göç kılavuzu topluca geçişi zorunlu kılmıyor; iki framework aynı hedefte ve dosyada bir arada durabiliyor.

Checkout, ödeme ekranı gibi kritik akışlar için UI otomasyonu kurman gerekiyor

Öneri: XCTest/XCUITest kullan.

Swift Testing'in UI otomasyon API karşılığı yok; Apple dokümantasyonu bunu açıkça XCTest'e bırakıyor.

Scroll performansı veya başlatma süresi gibi metrikleri CI'de izlemek istiyorsun

Öneri: XCTMetric ile XCTest tabanlı Performance Test yaz.

Performance Testleri resmi olarak yalnızca XCTest kapsamında; Swift Testing'de eşdeğeri yok.

Testlerin paylaşılan bir DB fixture veya singleton'a dayanıyor

Öneri: Swift Testing'e geçerken ilgili suite'i .serialized trait'iyle işaretle veya fixture'ı test başına yeniden oluştur.

Varsayılan paralel çalıştırma, paylaşılan durumu olan eski test mantığında race condition'ı açığa çıkarabiliyor.

Swift paketini Linux/Windows CI'de de test etmen gerekiyor

Öneri: İkisi de çalışır; yeni testlerde Swift Testing'i tercih et, mevcut XCTest hedeflerini taşımak zorunda değilsin.

swift-corelibs-xctest sayesinde 'swift test' Linux/Windows'ta XCTest hedeflerini de koşuyor (Xcode 7 API alt kümesi); platforma bağlı kalan asıl kısım XCUITest.

Yaygın Tuzaklar

  • #expect içinde throw edilen bir hatanın sonraki expectation'ları sessizce durdurması

    Swift Testing

    Çözüm

    Ön koşul niteliğindeki kontroller için #expect yerine #require kullan, ya da hatayı do/catch ile yakalayıp ayrı işle.

  • Varsayılan paralel çalıştırmada paylaşılan durumun (DB fixture, singleton, mock dosya sistemi) race condition yaratması

    Swift Testing

    Çözüm

    İlgili suite'i .serialized trait'iyle işaretle veya her test için taze fixture oluştur; global olarak gerekirse --no-parallel kullan.

  • Aynı test fonksiyonu içinde XCTest ve Swift Testing API'lerini karıştırmaya çalışmak

    Her ikisi

    Çözüm

    İki framework'ü aynı hedefte/dosyada tut ama her test fonksiyonunu tek bir framework'ün API'siyle yaz.

  • UI veya performans testini Swift Testing'e taşımaya çalışmak

    Her ikisi

    Çözüm

    XCUITest ve XCTMetric gerektiren testleri XCTest'te bırak; bu ikisi Swift Testing kapsamında değil.

  • Eski Xcode sürümü veya Swift 6 altı araç zincirinde Swift Testing'i kullanmaya çalışmak

    Swift Testing

    Çözüm

    Swift Testing için minimum Xcode 16 / Swift 6 araç zincirine yükselt; yükseltemiyorsan yeni testleri de XCTest'te yaz.

Geçiş Kılavuzu

XCTest'ten Swift Testing'e (kademeli)

Tahmini süre: Orta ölçekli bir modül (50-150 test) için 1-2 sprint; tüm paket için topluca değil, modül modül kademeli göç önerilir.
  1. 1Xcode 16+ / Swift 6 araç zincirine yükselt ve interop modunu kontrol et (SWIFT_TESTING_XCTEST_INTEROP_MODE).
  2. 2Yeni yazılacak birim/entegrasyon testlerini doğrudan Swift Testing ile başlat; mevcut XCTest dosyalarına dokunma.
  3. 3Taşımak istediğin bir dosyada import XCTest yerine import Testing kullan, XCTestCase alt sınıfını @Suite struct'a çevir.
  4. 4XCTAssert* çağrılarını karşılık gelen #expect/#require ifadelerine tek tek dönüştür; her dönüşümde testi çalıştırıp doğrula.
  5. 5Döngüyle taklit edilen parametreli testleri @Test(arguments:) ile sadeleştir.
  6. 6Paylaşılan durumu olan testleri işaretleyip .serialized trait'i ekle, ardından paralel çalıştırmayı aç.
  7. 7UI ve Performance Testlerini bilinçli olarak XCTest'te bırak — bunlar göç kapsamı dışında.
  8. 8CI pipeline'ında her iki framework'ün de xcresult çıktısını doğru topladığını doğrula.

Gelecek Öngörüsü

Swift Testing

Swift Testing, Apple'ın birim/entegrasyon test yatırımının merkezinde: Swift 6.3 (24 Mart 2026) test iptalini ve uyarı-seviyeli issue'ları, Swift 6.4 (15 Eylül 2026) ise çapraz-framework raporlamayı getirdi; ST-0024 ile test tekrarı test-case bazına indi ve 'swift test'e --maximum-repetitions/--repeat-until bayrakları eklendi. Güncel araç zinciri Xcode 27 final (14 Eylül 2026); yol haritası Apple'ın resmi swift.org duyurularıyla düzenli genişliyor.

XCTest

XCTest deprecate edilmedi: Apple WWDC24'te UI otomasyonu (XCUIApplication), performans testleri (XCTMetric) ve yalnızca Objective-C ile yazılabilen testler için XCTest'i kullanmaya devam etmeni birebir söylüyor. Yeni birim testi ergonomisi Swift Testing'de gelişirken Swift 6.4'teki çapraz-framework interop iyileştirmesi XCTest tarafını da dolaylı güçlendirdi.

Altın Bilgi

Bu karşılaştırmanın en değerli çıkarımı, sorunun 'hangisi kazanacak' değil 'hangi test XCTest'te kalmak zorunda' olması. Apple dokümantasyonu UI otomasyonu ve Performance Testlerini açıkça XCTest'e bırakıyor — bu eksiklik değil, tasarım kararı. Doğru mimari soru 'ne zaman göç edeyim' değil, 'test hedefimi baştan iki katmanlı mı kurayım': birim/entegrasyon Swift Testing'de, UI/performans XCTest'te, aynı hedefte yan yana. Swift 6.4'ün çapraz-framework raporlaması bu iki katmanı tek güvenlik ağı gibi çalıştırıyor — bir framework'teki başarısızlık diğerinde de görünür. Bu da 'topluca göç' baskısını kaldırıyor: kademeli, dosya dosya geçiş hem güvenli hem Apple'ın önerdiği yol.

İlgili Blog Yazıları

Tüm Yazıları Gör

İlgili Projeler

Tüm Projeleri Gör

İlgili İçerik