Swift Testing 還是 XCTest？2026 新手選擇指南

剛在 Xcode 建立測試目標，卻不知道該選 Swift Testing 還是 XCTest？

最快的解法是：新專案的單元測試與整合測試優先用 Swift Testing；UI 測試繼續用 XCTest。舊課程或現有 XCTest 專案不用全部重寫，讓兩套框架共存，再按課程要求逐步遷移即可。Apple 官方已確認兩者可以放在同一個測試目標中。查看 Apple 的測試專案說明

這篇適合第一次看到 @Test、#expect 與 XCTestCase 的 Swift 初學者；也適合正在提交舊課程作業、接手 XCTest 專案，或只有 Windows、學校電腦與受限設備的學習者。文章不討論測試理論，而是協助讀者在實際交作業前作出不容易出錯的選擇。

先把兩套框架分成兩種檢查工作

可以把測試想成提交作業前的自動檢查。

Swift Testing 比較適合檢查函式的邏輯。例如，輸入兩個數字後，結果是否正確；購物車加入商品後，總額是否符合預期。這類測試不需要模擬滑鼠點擊，也不需要操作畫面。

XCTest 則仍負責 UI 測試。它可以啟動 App、尋找畫面上的按鈕、輸入文字，再檢查頁面是否出現預期內容。這比較像請另一位同學按照操作步驟重新驗收 App。

在新專案中，兩者不是互相排斥的選項：

• 邏輯與資料處理：優先使用 Swift Testing。
• 非同步邏輯與整合流程：可使用 Swift Testing，前提是專案環境與課程支援。
• 畫面點擊與 UI 自動化：保留 XCTest。
• 舊課程指定的測試類別：先保留 XCTest，不要為了追新而改寫。

Apple 的新建測試專案文件同時列出 Swift Testing 與 XCTest UI Tests，這也是新手最可靠的判斷入口，而不是只看網路文章中的「新舊框架」標籤。Apple 新建測試專案文件

新專案：Swift Testing 還是 XCTest，先看測試內容

Swift 新專案應該選擇哪一套？
如果是剛建立的 Swift 或 SwiftUI 專案，且目前要測試的是函式、模型、資料轉換或非同步邏輯，優先採用 Swift Testing。這個決定不是因為「新框架一定比較快」，而是因為它的測試寫法較容易直接表達測試案例，也支援參數化測試與並行相關情境。參數化測試可以理解為：同一道題目，拿多組資料逐一批改，而不是複製多個幾乎相同的測試函式。

一個可丟棄的入門函式如下：

import Testing

func double(_ value: Int) -> Int {
    value * 2
}

@Test
func doubleReturnsExpectedValue() {
    #expect(double(3) == 6)
}

這段程式不需要先理解完整測試理論：

• @Test 告訴 Xcode，下面的函式是一個測試案例。
• #expect 是判分條件，用來檢查結果是否符合預期。
• double(3) == 6 是這次作業的具體答案。

#expect 的用途與使用方式，可對照 Apple 對 expectations 的官方說明。如果測試失敗，Xcode 會把失敗位置與表達式顯示在測試結果中，讀者便能知道是函式錯誤，還是預期值寫錯。

當測試的是登入流程、列表滑動或按鈕點擊，則不要硬把 UI 工作改寫成 Swift Testing。UI Tests 仍由 XCTest 承擔：

import XCTest

final class LoginUITests: XCTestCase {
    func testLoginButtonAppears() {
        let app = XCUIApplication()
        app.launch()

        XCTAssertTrue(app.buttons["登入"].exists)
    }
}

這裡的 XCTestCase、App 啟動與按鈕搜尋，都是 UI 驗收的一部分。Apple 的 XCTest 文件仍以測試案例與測試方法作為 UI 測試的基本結構。XCTest 測試案例文件

舊課程與現有專案：先保交作業，再談遷移

已有 XCTest 作業，需要全部遷移嗎？
不需要。若老師的範例、測試目標、檔案名稱或提交方式都以 XCTest 為前提，最穩妥的做法是先讓原有測試正常執行。作業接近截止、目前測試基線尚未通過，或課程明確要求 XCTestCase 時，應停止遷移。

「測試目標」可以想成 Xcode 裡負責收集和執行測試的作業資料夾。只要原有測試仍能被這個目標找到，新增加的 Swift Testing 測試可以逐步放入相同目標。這就是漸進遷移：不是一次把整份作業換掉，而是先保留能交付的部分，再讓新測試使用較合適的寫法。

遷移前可依照以下條件判斷：

• 若老師要求 XCTest，選 保留 XCTest。
• 若截止時間很近，選 不遷移。
• 若舊測試已全部通過，才考慮加入新的 Swift Testing 案例。
• 若新功能是純 Swift 邏輯，選 新增 Swift Testing。
• 若新功能是畫面操作，選 繼續使用 XCTest UI Tests。
• 若測試結果在遷移後出現警告或遺漏，回退到原有測試，先完成作業驗收。

Apple 的遷移資料明確說明，Swift Testing 與 XCTest 可以在同一測試目標中逐步並存。這代表「共存」不是臨時取巧，而是官方支援的工作方式。Apple 的 XCTest 遷移文件

小組專案：不要只按個人偏好替換測試

接手別人的 Git 儲存庫時，第一步不是把所有 XCTAssert 搜尋取代成 #expect。先檢查以下內容：

• 目前有哪些測試檔案與測試目標。
• 是否有共用的測試輔助函式。
• 測試計畫是否固定包含某些 UI Tests。
• CI 或老師的驗收流程是否仍依賴 XCTest 結果。
• 失敗測試是被判定為失敗，還是只留下警告。

測試互操作可以理解為兩套批改規則放在同一個教室：它們可以在同一個測試目標中工作，但不代表每個舊有設定都會自動產生完全相同的結果。Xcode 27 的測試相關能力與互操作方式，應以 Apple 的遷移說明及 WWDC26 影片中的實際設定為準，不應自行推測 XCTest 的淘汰時間。WWDC26 測試遷移影片

遷移時，應在前後都執行同一組測試，再比較失敗清單。若原本會被判定為失敗的案例，遷移後只顯示警告，不能把它當成通過。測試有跑完，不等於測試真的驗證了錯誤情況。

可採用這個小流程：

保留原測試
  ↓
執行並記錄失敗案例
  ↓
新增一個 Swift Testing 案例
  ↓
再次執行相同測試範圍
  ↓
比較失敗、警告與測試結果

截至 2026 年 9 月 18 日，Apple 已確認 Swift Testing 與 XCTest 的共存方向；Swift 6.4 與 Xcode 27 的具體互操作行為，仍應以官方版本文件和當前專案設定核對。Xcode 系統要求 Swift 6.4 發布說明

沒有 Mac 時，先練邏輯，後驗收 UI

沒有 Mac，可以練習 Swift Testing 嗎？
可以先練習一部分。Swift.org 說明，Swift Testing 可用於 Swift 所支援的主要平台，因此純 Swift 函式與 Swift Package 的測試，能先在非 Mac 環境建立基本練習。Swift Testing 平台說明

但這不等於 Windows 能完整取代 Xcode 與 Mac。以下工作仍可能需要 Mac 環境：

• 建立和管理 iOS 或 SwiftUI 專案。
• 啟動 iOS 模擬器。
• 執行 XCTest UI Tests。
• 檢查畫面點擊、裝置尺寸與 App 啟動流程。
• 按照課程要求保存完整的 Xcode 測試結果。

因此，沒有 Mac 的學習者可先建立一個小型 Swift Package，將資料模型和純函式放入其中，再把程式碼同步到學校 Mac、借用設備或遠端真實 Mac。不要等到作業截止前才第一次測試連線、測試執行和結果保存。

SFTPMAC 的遠端 Mac 服務入口適合用來處理短期 Xcode 驗收需求。若只是完成一個課程項目，可先查看遠端 Mac 方案與價格，再按課程期限判斷是否值得租用。遠端方式不能消除網路延遲，也不能取代需要實體 iPhone 或特定 USB 配件的課程；它的價值在於提供一個可連線的真實 macOS 環境，讓測試流程可以被實際跑完。

用條件分支完成最後選擇

可把以下清單當成提交前的決策工具：

• 若是新建立的 Swift 或 SwiftUI 專案，正在測試純邏輯，選 Swift Testing。
• 若是新建立的專案，正在測試按鈕、畫面與使用者流程，選 XCTest UI Tests。
• 若是舊課程已指定 XCTest，選 保留 XCTest，不要為了版本新舊而重寫。
• 若是接手現有專案，先看測試計畫與共用輔助程式，再決定是否漸進加入 Swift Testing。
• 若只有 Windows，先用 Swift Package 練純 Swift；進入 iOS UI、模擬器或 UI 自動化時，改用學校 Mac、借用設備或遠端 Mac。
• 若遷移後測試失敗結果與原本不同，回退到原有測試，先確認兩套框架的執行範圍和結果判定。

提交前，至少確認以下事項：

• 測試案例確實出現在 Xcode 測試結果中。
• 故意製造的錯誤會顯示為失敗，而不是只有警告。
• UI 流程仍由 XCTest 驗證。
• 專案符合老師指定的框架和檔案結構。
• 其他同學可以在目標環境重新執行測試。
• Windows 上的練習程式已同步到能執行 Xcode 的環境。

目前使用 Windows 或受限電腦，常見缺點是無法直接完成 Xcode 專案驗收、不能在同一台設備上檢查 iOS 模擬器，且學校電腦可能限制軟體安裝；只靠雲端編輯器也難以驗證 XCTest UI 流程。若只是短期完成課程作業，租用 SFTPMAC 的遠端真實 Mac，通常比為一次測試立刻購買 Mac 更容易控制成本與使用期限；若之後要長期進行高負載開發、需要實體裝置或 USB 介面，則應重新評估自購設備或使用學校實驗室。

完成框架選擇後，最安全的下一步是建立一個可刪除的小專案：用 Swift Testing 驗證一個純 Swift 函式，再用 XCTest 驗證一個簡單的 UI 點擊流程。兩邊都能正確顯示成功與失敗，再把方法帶回正式作業，會比直接修改整份舊專案更不容易在提交前出現意外。