前言

編程語言中的單元測試是為了確保編寫的代碼按預(yù)期工作。給定一個特定的輸入，您希望代碼帶有一個特定的輸出。通過測試您的代碼，能夠給您當(dāng)前的重構(gòu)和發(fā)布建立信心，因為您將能夠確保代碼在成功運(yùn)行您的測試套件后按預(yù)期工作。

許多開發(fā)人員不編寫單元測試，因為他們認(rèn)為這會花費(fèi)太多時間，有可能錯過最后期限。在我看來，單元測試會讓你在最后期限前完成更多工作，因為你會花更少的時間解決錯誤或為關(guān)鍵問題打補(bǔ)丁。

(相關(guān)資料圖)

這篇文章內(nèi)不會涵蓋 內(nèi)存泄漏測試 或 為共享擴(kuò)展編寫 UI 測試，而是主要關(guān)注編寫更好的單元測試。我還將分享幫助我開發(fā)更好、更穩(wěn)定的應(yīng)用程序的最佳實(shí)踐。

什么是單元測試

單元測試是運(yùn)行和驗證一段代碼（稱為“單元”）以確保其按預(yù)期運(yùn)行并符合其設(shè)計的自動化測試。

單元測試在 Xcode 中有它們的 target，并使用 XCTest 框架編寫。XCTestCase的子類包含要運(yùn)行的測試方法，其中只有以 "test" 開頭的方法才會被 Xcode 解析并允許運(yùn)行。

例如，假設(shè)有一個字符串?dāng)U展方法將第一個字母大寫：

extension String {    func uppercasedFirst() -> String {        let firstCharacter = prefix(1).capitalized        let remainingCharacters = dropFirst().lowercased()        return firstCharacter + remainingCharacters    }}

我們要確保uppercasedFirst()方法按預(yù)期工作。如果我們給它一個輸入antoine，我們期望它輸出Antoine。我們可以使用XCTAssertEqual方法為此方法編寫單元測試：

final class StringExtensionsTests: XCTestCase {    func testUppercaseFirst() {        let input = "antoine"        let expectedOutput = "Antoine"        XCTAssertEqual(input.uppercasedFirst(), expectedOutput, "The String is not correctly capitalized.")    }}

如果我們的方法不再按預(yù)期工作(比如上面的擴(kuò)展代碼不小心被修改了)，Xcode 將使用我們提供的描述顯示失?。?/p>

在 Swift 中編寫單元測試

有多種方法可以測試相同的結(jié)果，但是當(dāng)測試失敗時它并不總是給出相同的反饋。以下提示可幫助您編寫測試，通過從詳細(xì)的失敗消息中獲益，幫助您更快地解決失敗的測試。

命名測試用例和方法

描述你的單元測試是很重要的，這樣你就會明白測試試圖驗證什么。如果你不能想出一個簡短的名字，那你可能測試了太多東西。一個好名字還可以幫助您更快地解決失敗的測試。

要快速找到特定類的測試用例，建議使用相同的命名并結(jié)合 “test”。就像上面的例子一樣，我們根據(jù)我們正在測試一組字符串?dāng)U展的事實(shí)命名了StringExtensionTests。如果您正在測試ContentViewModel實(shí)例，另一個示例可能是ContentViewModelTests。

不要所有測試都使用 XCTAssert

許多場景都可以使用XCTAssert，但當(dāng)測試失敗時會導(dǎo)致不同的結(jié)果。以下代碼行都測試了完全相同的結(jié)果：

func testEmptyListOfUsers() {    let viewModel = UsersViewModel(users: ["Ed", "Edd", "Eddy"])    XCTAssert(viewModel.users.count == 0)    XCTAssertTrue(viewModel.users.count == 0)    XCTAssertEqual(viewModel.users.count, 0)}

正如你所看到的，該方法使用了一個描述性的名字，告訴人們要測試一個空的用戶列表。然而，我們定義的視圖模型不是空的，因此，所有的斷言都失敗了。

結(jié)果顯示了為什么必須對驗證類型使用正確的斷言。XCTAssertEqual方法為我們提供了有關(guān)斷言失敗原因的更多上下文。這顯示在紅色錯誤和控制臺日志中，可幫助您快速識別失敗的測試。

Setup and Teardown

多個測試方法中使用的參數(shù)可以定義為測試用例類中的屬性。您可以使用setUp()方法為每個測試方法設(shè)置初始狀態(tài)，并使用tearDown()方法進(jìn)行清理。有多種設(shè)置和拆卸方法的變體供您選擇，例如支持并發(fā)的變體或拋出變體，如果設(shè)置失敗，您可以在其中提前使測試失敗。

一個可以生成用戶默認(rèn)實(shí)例以用于單元測試的示例：

struct SearchQueryCache {    var userDefaults: UserDefaults = .standard    func storeQuery(_ query: String) {        /// ...    }}final class SearchQueryCacheTests: XCTestCase {    private var userDefaults: UserDefaults!    private var userDefaultsSuiteName: String!    override func setUpWithError() throws {        try super.setUpWithError()        userDefaultsSuiteName = UUID().uuidString        userDefaults = UserDefaults(suiteName: userDefaultsSuiteName)    }    override func tearDownWithError() throws {        try super.tearDownWithError()        userDefaults.removeSuite(named: userDefaultsSuiteName)        userDefaults = nil    }    func testSearchQueryStoring() {        /// 使用生成的用戶默認(rèn)值作為輸入。        let cache = SearchQueryCache(userDefaults: userDefaults)        /// ... write the test    }}

這樣做可以確保您不會操縱在模擬器上測試期間使用的標(biāo)準(zhǔn)用戶默認(rèn)值。其次，您將確保在測試開始時處于干凈狀態(tài)。我們使用了拆卸方法來刪除用戶默認(rèn)套件并進(jìn)行相應(yīng)的清理。

拋出方法

和編寫應(yīng)用程序代碼時一樣，您也可以定義一個可拋出測試的方法。這允許您在測試中的方法拋出錯誤時使測試失敗。例如，在測試 JSON 響應(yīng)的解碼時：

func testDecoding() throws {    /// 當(dāng)數(shù)據(jù)初始值設(shè)定項拋出錯誤時，測試將失敗。    let jsonData = try Data(contentsOf: URL(string: "user.json")!)    /// `XCTAssertNoThrow` 可用于獲取有關(guān)拋出的額外上下文    XCTAssertNoThrow(try JSONDecoder().decode(User.self, from: jsonData))}

當(dāng)在任何進(jìn)一步的測試執(zhí)行中不需要 throwing 方法的結(jié)果時，可以使用XCTAssertNoThrow方法。您應(yīng)該使用XCTAssertThrowsError方法來匹配預(yù)期的錯誤類型。例如，您可以為證書密鑰驗證程序編寫測試：

struct LicenseValidator {    enum Error: Swift.Error {        case emptyLicenseKey    }    func validate(licenseKey: String) throws {        guard !licenseKey.isEmpty else {            throw Error.emptyLicenseKey        }    }}class LicenseValidatorTests: XCTestCase {    let validator = LicenseValidator()    func testThrowingEmptyLicenseKeyError() {        XCTAssertThrowsError(try validator.validate(licenseKey: ""), "An empty license key error should be thrown") { error in            /// 我們確保預(yù)期的錯誤被拋出。            XCTAssertEqual(error as? LicenseValidator.Error, .emptyLicenseKey)        }    }    func testNotThrowingLicenseErrorForNonEmptyKey() {        XCTAssertNoThrow(try validator.validate(licenseKey: "XXXX-XXXX-XXXX-XXXX"), "Non-empty license key should pass")    }}

可選值解包

XCTUnwrap方法最適合用于拋出測試，因為它是一個拋出斷言：

func testFirstNameNotEmpty() throws {    let viewModel = UsersViewModel(users: ["Antoine", "Maaike", "Jaap"])    let firstName =  try XCTUnwrap(viewModel.users.first)    XCTAssertFalse(firstName.isEmpty)}

XCTUnwrap斷言可選變量的值不為nil，如果斷言成功則返回它的值。它會阻止您編寫XCTAssertNotNil并結(jié)合解包或處理其余測試代碼的條件鏈接。

在 Xcode 中運(yùn)行單元測試

編寫測試后，就該運(yùn)行它們了。通過以下提示，這將變得更有效率。

使用測試三角形

您可以使用前導(dǎo)三角形運(yùn)行單個測試或一組測試：

根據(jù)最新的測試運(yùn)行結(jié)果，同一方塊顯示紅色或綠色。

重新運(yùn)行最新的測試

使用以下命令重新運(yùn)行上次運(yùn)行測試：

? Control + ? Option + ? Command + G.

上面的快捷方式可能是我最常用的快捷方式之一，因為它可以幫助我在對失敗測試實(shí)施修復(fù)后快速重新運(yùn)行測試。

運(yùn)行測試組合

使用 CTRL 或 SHIFT 選擇要運(yùn)行的測試，右鍵單擊并選擇“Run X Test Methods”。

在測試導(dǎo)航器中應(yīng)用過濾器

測試導(dǎo)航器底部的過濾欄允許您縮小測試概覽范圍。

使用搜索字段根據(jù)名稱搜索特定測試僅顯示當(dāng)前所選方案的測試。如果您有多個測試方案，這將很有用。只顯示失敗的測試。這將幫助您快速找到失敗的測試。在側(cè)邊欄中啟用覆蓋

測試迭代計數(shù)向您顯示在上次運(yùn)行測試期間是否命中了特定代碼段。

它顯示了迭代次數(shù)（在上面的示例中為 3），一段代碼在到達(dá)時變?yōu)榫G色。當(dāng)一段代碼是紅色時，這意味著它在上次運(yùn)行的測試中沒有被覆蓋。

編寫單元測試時的心態(tài)

你的心態(tài)是編寫高質(zhì)量單元測試的一個很好的起點(diǎn)。通過一些基本原則，您可以確保工作效率、保持專注并編寫您的應(yīng)用程序最需要的測試。

您的測試代碼與您的應(yīng)用程序代碼一樣重要

在深入探討實(shí)用技巧之后，我想介紹一種必要的心態(tài)。就像編寫應(yīng)用程序代碼一樣，您應(yīng)該盡最大努力編寫高質(zhì)量的測試代碼。

考慮重用代碼、使用協(xié)議、在多個測試中使用時定義屬性，并確保您的測試清理所有創(chuàng)建的數(shù)據(jù)。這將使您的單元測試更易于維護(hù)，并防止不穩(wěn)定和奇怪的測試失敗。

100% 的代碼覆蓋率不應(yīng)該是你的目標(biāo)

盡管它是很多人的目標(biāo)，但 100% 的覆蓋率不應(yīng)該是您編寫測試時的主要目標(biāo)。一個很好的開始是確保至少測試您最關(guān)鍵的業(yè)務(wù)邏輯。覆蓋率達(dá)到 100% 可能會很耗時，而收益并不總是那么顯著。并且達(dá)到100%，也意味著可能需要付出很大的努力。

最重要的是，100% 的覆蓋率可能會產(chǎn)生誤導(dǎo)。上面的單元測試示例覆蓋了所有方法，覆蓋率為 100%。但是，它并沒有測試所有場景，因為它只測試了一個非空數(shù)組。同時，也可能存在空數(shù)組的情況，其中hasUsers屬性應(yīng)該返回 false。

您可以從 Scheme 設(shè)置窗口啟用測試覆蓋率。這個窗口可以通過Product ? Scheme ? Edit Scheme打開。

在修復(fù)錯誤之前編寫測試

跳到一個錯誤上并盡快修復(fù)它是很誘人的。雖然這很好，但如果您可以防止將來再次出現(xiàn)相同的錯誤，那就更好了。通過在修復(fù) bug 之前編寫單元測試，可以確保相同的 bug 不會再次發(fā)生。將其視為“測試驅(qū)動的錯誤修復(fù)”，從現(xiàn)在開始也稱為 TDBF 。

其次，您可以開始編寫修復(fù)程序并運(yùn)行新的單元測試來驗證修復(fù)程序是否有效。此技術(shù)比運(yùn)行模擬器來驗證您的修復(fù)是否有效要快。

結(jié)論

編寫定性的單元測試是開發(fā)人員的基本技能。將能夠?qū)δ拇a庫建立信心，確保您在新版本發(fā)布之前沒有破壞任何東西。使用正確的斷言，您可以更快地解決失敗的測試。確保至少測試關(guān)鍵業(yè)務(wù)代碼并避免達(dá)到 100% 的代碼覆蓋率。

關(guān)鍵詞：