Untuk memberikan setiap senario hasil dan kawalan jalankan semula tersendiri dalam Xcode, pindahkan ujian unit XCTest berasaskan gelung kepada @Test berparameter dalam Swift Testing. Panduan ini menggunakan pengiraan susun atur jubin setempat untuk menunjukkan migrasi dan mengesahkan tingkah laku pelaporannya.

Mengapa gelung XCTest tidak melaporkan setiap senario secara berasingan?

XCTest menemui kaedah ujian pada subkelas XCTestCase. Kaedah ini tidak menerima parameter dan namanya bermula dengan test. Gelung di dalam satu kaedah yang ditemui kekal sebagai sebahagian daripada kaedah itu; lelarannya tidak menjadi ujian yang ditemui secara berasingan. Menambahkan nama senario pada pernyataan boleh memperbaik diagnostik, tetapi tidak mewujudkan kawalan jalankan yang tersendiri. Lihat Mentakrifkan Kes Ujian dan Kaedah Ujian oleh Apple.

Kitar hayat mengikut sempadan yang sama. XCTest menjalankan kaedah persediaan instance sebelum setiap kaedah ujian dan kaedah pembersihan selepasnya. Oleh itu, gelung lima lelaran tidak secara automatik menerima lima kitaran persediaan dan pembersihan. Jika satu lelaran mengubah fixture, lelaran seterusnya mungkin mewarisi keadaan itu melainkan ujian menetapkannya semula secara jelas. Apple mendokumenkan urutan ini dalam Sediakan dan Bersihkan Keadaan dalam Ujian Anda.

Swift Testing menyediakan hasil yang diperlukan di sini: satu fungsi menerima argumen senario, dan pelari menganggap setiap pemanggilannya sebagai kes yang bebas. Xcode memaparkan argumennya dan menawarkan kawalan jalankan individu. Apple menunjukkan tingkah laku ini dalam Terokai Swift Testing dengan lebih lanjut.

Perbezaan ini penting semasa mendiagnosis kegagalan. Kegagalan pernyataan dan keluar awal ialah peristiwa yang berbeza: gelung boleh terus membuat semakan selepas pernyataan biasa, manakala ralat yang dilemparkan atau return yang jelas boleh menghalang lelaran seterusnya daripada dijalankan. Mengasingkan senario sebagai kes menghapuskan aliran kawalan bersama antara senario. Ini tidak menjadikan kegagalan yang menamatkan proses boleh dipulihkan.

Sediakan sasaran ujian unit sedia ada

Gunakan Xcode 16 atau lebih baharu untuk aliran kerja ini. Swift Testing disertakan dalam edaran Xcode tersebut dan dalam toolchain Swift.org bermula dengan Swift 6.0. Projek Swift mengesyorkan penggunaan salinan terbina dalam untuk kerja ujian biasa; contoh ini tidak memerlukan kebergantungan pakej luaran. Lihat Mendapatkan Swift Testing.

Kekalkan bundle ujian unit sedia ada. Apple menyokong Swift Testing dan XCTest dalam sasaran yang sama secara jelas, jadi migrasi berperingkat boleh bermula dengan satu fail Swift baharu. Dalam Xcode, pilih File > New > New File From Template, pilih Swift Testing Unit Test, kemudian tambahkan fail itu kepada sasaran ujian unit sedia ada. Jika projek tiada sasaran ujian, cipta Unit Testing Bundle melalui File > New > Target. Langkah ini didokumenkan dalam Menambahkan ujian pada projek Xcode anda.

Panduan ini menguji kod pengiraan secara langsung. Ia tidak mengautomasikan tetingkap desktop. Laluan yang didokumenkan Apple untuk automasi UI terus menggunakan XCTest; gunakan pendekatan berparameter ini untuk logik asas yang menentukan susun atur. Panduan menambahkan ujian yang sama menerangkan sempadan rangka kerja itu.

Jadikan setiap senario satu rekod argumen lengkap

Katakan aplikasi Mac menyusun jubin dalam baris. Dengan empat lajur, sifar jubin memerlukan sifar baris, empat jubin memenuhi satu baris, dan lima jubin memerlukan dua baris. Tugas khususnya ialah mengekalkan semakan tersebut sambil menjadikan setiap senario kelihatan dan boleh dijalankan secara berasingan.

Gunakan satu rekod yang mengandungi nama senario, input dan output yang dijangka. Ini memastikan hasil yang dijangka kekal dipadankan dengan inputnya apabila kes ditambah atau disusun semula. Lima rekod berikut ialah data ujian ilustrasi, bukannya pemerhatian daripada aplikasi sedia ada.

Senario Bilangan jubin Lajur Baris dijangka Tujuan
empty 0 4 0 Input kosong
one-tile 1 4 1 Baris pertama tidak penuh
exact-row 4 4 1 Sempadan tepat
wrap 5 4 2 Jubin pertama melebihi sempadan
two-full-rows 8 4 2 Gandaan tepat

Letakkan fail lengkap yang kendiri ini dalam sasaran ujian unit. Fail ini mengandungi pelaksanaan sintetik supaya boleh dicuba tanpa modul aplikasi atau fail lain. Ia tidak menggunakan perkhidmatan, mock, fail atau akses rangkaian.

import Testing

private struct TileLayout {
    func rowCount(tileCount: Int, columns: Int) -> Int {
        precondition(tileCount >= 0)
        precondition(columns > 0)

        let fullRows = tileCount / columns
        let partialRow = tileCount % columns == 0 ? 0 : 1
        return fullRows + partialRow
    }
}

private struct LayoutScenario:
    Codable, Sendable, CustomTestStringConvertible {
    let name: String
    let tileCount: Int
    let columns: Int
    let expectedRows: Int

    var testDescription: String { name }

    static let examples: [LayoutScenario] = [
        .init(name: "empty", tileCount: 0,
              columns: 4, expectedRows: 0),
        .init(name: "one-tile", tileCount: 1,
              columns: 4, expectedRows: 1),
        .init(name: "exact-row", tileCount: 4,
              columns: 4, expectedRows: 1),
        .init(name: "wrap", tileCount: 5,
              columns: 4, expectedRows: 2),
        .init(name: "two-full-rows", tileCount: 8,
              columns: 4, expectedRows: 2)
    ]
}

struct TileLayoutTests {
    @Test("Tile rows", arguments: LayoutScenario.examples)
    fileprivate func rowCountMatchesScenario(
        _ scenario: LayoutScenario
    ) {
        let layout = TileLayout()
        let actualRows = layout.rowCount(
            tileCount: scenario.tileCount,
            columns: scenario.columns
        )
        #expect(actualRows == scenario.expectedRows)
    }
}

Migrasi ini memindahkan lelaran ke dalam @Test(arguments:): setiap elemen menjadi argumen untuk satu pemanggilan. Codable menyediakan sokongan pengekodan untuk jalankan semula terpilih, manakala CustomTestStringConvertible menyediakan label senario yang mudah dibaca. Apple mendokumenkan pemparameteran dalam Melaksanakan ujian berparameter dan perihalan argumen tersuai dalam Terokai Swift Testing dengan lebih lanjut.

Fixture sengaja dibina di dalam fungsi ujian. Setiap pemanggilan menghasilkan TileLayout tersendiri; tiada apa-apa yang bergantung pada senario sebelumnya. Jika anda memigrasikan fixture sedia ada, pindahkan persediaannya dengan teliti dan jangan menjangkakan hook XCTest yang diwarisi akan dijalankan. Suite Swift Testing tidak mewarisi XCTestCase; Apple memadankan persediaan dengan pemula dan pembersihan kelas atau aktor dengan deinit dalam Memigrasikan ujian daripada XCTest.

Pengiraan ini menerima bilangan jubin bukan negatif dan bilangan lajur positif sepenuhnya. Prasyaratnya mentakrifkan kontrak tersebut; nilai tidak sah berada di luar skop kes dalam contoh ini. Jika kod aplikasi sebenar perlu memulangkan ralat yang boleh dipulihkan untuk input tidak sah, ubah kontrak API itu dan tambahkan ujian yang berkenaan sebelum meluaskan jadual ini.

Sahkan hasil berasingan dan jalankan semula satu kes yang gagal

Jalankan fungsi berparameter menggunakan ikon berlian di sebelah pengisytiharannya. Kemudian buka Test navigator dan kembangkan fungsi itu untuk memeriksa kesnya. Untuk menjalankan satu kes, halakan penuding pada ikon berlian kes itu dan klik kawalan mainnya. Mengklik kawalan main fungsi induk akan menjalankan semua kesnya. Apple mendokumenkan kedua-dua tindakan ini dalam Menjalankan ujian dan mentafsir hasil.

Untuk semakan pelaporan terkawal, ubah sementara wrap dalam rekod kepada expectedRows daripada 2 kepada 3. Jalankan seluruh fungsi berparameter. Hasil yang dijangka ialah lima pelaksanaan kes, dengan perbandingan wrap gagal kerana pelaksanaan memulangkan 2. Pilih kes itu dan jalankan semula secara individu, kemudian pulihkan nilai yang dijangka kepada 2. Ini ialah perubahan data ujian yang disengajakan, bukannya bukti kecacatan pelaksanaan.

Periksa butiran Results dan Arguments bagi jangkaan yang gagal untuk membandingkan nilai yang dikira dengan input senario. Bagi keseluruhan larian, buka View > Navigators > Reports, pilih tindakan ujian, kemudian periksa bahagian Testsnya. Kawalan pemeriksaan ini diterangkan dalam panduan hasil ujian oleh Apple.

Pelaksanaan terpilih mempunyai satu lagi keperluan selain label yang mudah dibaca: pelari mesti dapat memadankan setiap argumen secara deterministik. Dokumentasi semasa Apple menerima CustomTestArgumentEncodable, jenis RawRepresentable tertentu, Encodable, atau Identifiable dengan pengecam yang boleh dikodkan. Rekod Codable dalam contoh ini memenuhi laluan pengekodan tersebut. Rentetan paparan tersuai sahaja tidak memenuhi keperluan itu. Lihat Melaksanakan ujian berparameter.

Aritmetik yang dijangka untuk kelima-lima rekod disemak secara setempat menggunakan pembahagian integer dan baki Python. Pelaksanaan salah yang digunakan sebagai ilustrasi dan hanya menggunakan pembahagian lantai gagal pada one-tile dan wrap. Fail Swift telah diperiksa tetapi tidak dikompil dalam persekitaran penyelidikan ini kerana Swift tidak tersedia; larian Xcode di atas kekal sebagai langkah pengesahan boleh laksana.

Kekalkan bilangan kes dan kitar hayat yang dimaksudkan

Semakan migrasi yang berguna membandingkan tiga perkara: bilangan rekod senario, kes yang dilaksanakan dalam larian penuh, dan sama ada kes terpilih boleh dijalankan bersendirian. Bagi contoh ini, bilangan yang dimaksudkan ialah lima. Bilangan yang berbeza sepatutnya mendorong pemeriksaan pembinaan argumen dan pemilihan ujian sebelum pengiraan diubah.

Kekalkan jangkaan berpasangan bersama. Menghantar dua koleksi berasingan kepada arguments: akan menjana hasil darab Kartesian. Oleh itu, lima input dan lima output yang dijangka akan menghasilkan 25 kombinasi, bukannya lima senario berpadanan. Gunakan koleksi berasingan apabila setiap kombinasi bermakna; gunakan rekod atau zip() untuk data berpasangan. Apple menerangkan perbezaan itu dalam Melaksanakan ujian berparameter.

Jika menggunakan zip(), semak panjang koleksi sebelum membina pasangan: Swift berhenti pada jujukan yang lebih pendek. Hasil jangkaan tambahan mungkin tidak digunakan tanpa menghasilkan kes. Satu rekod senario mengelakkan ketidakpadanan khusus itu. Tingkah laku pemotongan tersebut didokumenkan dalam rujukan zip(::) Swift.

Turutan pelaksanaan juga mempengaruhi keputusan migrasi. Swift Testing menjalankan kes secara selari secara lalai. Contoh ini mempunyai argumen tidak berubah dan fixture setempat, jadi hasilnya tidak bergantung pada turutan. Untuk fungsi berparameter yang memerlukan pelaksanaan bersiri buat sementara waktu, tambahkan .serialized pada atribut @Testnya. Menggunakan trait itu pada suite juga menjadikan ujian dan kes di dalamnya bersiri, tetapi tidak menjadikan suite yang tidak berkaitan bersiri. Lihat Menjalankan ujian secara bersiri atau selari.

Pelaksanaan bersiri tidak menghasilkan keadaan baharu atau menetapkan kontrak kebergantungan antara senario. Jika sesuatu kes hanya berjaya selepas kes lain mengubah sesuatu, reka semula persediaannya supaya ia boleh dijalankan secara bebas. Jika langkah-langkah itu memang membentuk satu operasi berterusan, kekalkan semuanya dalam satu ujian dan parameterkan operasi lengkap sebagai gantinya.

Gunakan pernyataan Swift Testing sepanjang contoh yang dimigrasikan ini. Apabila menggunakan semula pembantu yang mengandungi pernyataan XCTest, semak tingkah laku saling kendali toolchain: panduan migrasi semasa Apple mendokumenkan mod dan lalai yang berbeza mengikut toolchain dan versi alat pakej. Mengekalkan seluruh fail ini dalam Testing mengelakkan kebergantungan itu. Lihat Memigrasikan ujian daripada XCTest.

Jika migrasi perlu ditangguhkan, alternatif XCTest yang disokong ialah satu kaedah ujian bernama tanpa parameter bagi setiap senario, dengan pembantu pengiraan dan pernyataan yang dikongsi apabila sesuai. Apple mengesyorkan satu ujian bagi setiap senario dalam panduan menambahkan ujian. Ini mengekalkan hasil kaedah yang berasingan tanpa memerlukan pemparameteran Swift Testing.

Penukaran selesai apabila setiap senario asal mempunyai kes sepadan yang telah dilaksanakan, fixture-nya bermula daripada keadaan yang dimaksudkan, dan kes terpilih boleh dijalankan sendiri dengan jayanya. Kekalkan input sempadan dan output yang dijangka semasa perubahan itu: pelaporan berasingan berguna kerana ia memudahkan semakan sedia ada dicari, didiagnosis dan diulangi.

Sumber