盗墓笔记txt全集下载,完美世界小说下载,辰东全部小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

Swift單元測試入門，你學會了嗎？

前言

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

成都網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁設(shè)計、成都網(wǎng)站建設(shè)、微信開發(fā)、微信小程序、集團成都定制網(wǎng)頁設(shè)計等服務(wù)項目。核心團隊均擁有互聯(lián)網(wǎng)行業(yè)多年經(jīng)驗，服務(wù)眾多知名企業(yè)客戶；涵蓋的客戶類型包括：成都集裝箱等眾多領(lǐng)域，積累了大量豐富的經(jīng)驗，同時也獲得了客戶的一致贊許！

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

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

什么是單元測試

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

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

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

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ù)期工作(比如上面的擴展代碼不小心被修改了)，Xcode 將使用我們提供的描述顯示失?。?/p>

在 Swift 中編寫單元測試

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

命名測試用例和方法

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

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

不要所有測試都使用 XCTAssert

許多場景都可以使用 XCTAssert，但當測試失敗時會導致不同的結(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() 方法進行清理。有多種設(shè)置和拆卸方法的變體供您選擇，例如支持并發(fā)的變體或拋出變體，如果設(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() {
        /// 使用生成的用戶默認值作為輸入。
        let cache = SearchQueryCache(userDefaults: userDefaults)

        /// ... write the test
    }
}

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

拋出方法

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

func testDecoding() throws {
    /// 當數(shù)據(jù)初始值設(shè)定項拋出錯誤時，測試將失敗。
    let jsonData = try Data(contentsOf: URL(string: "user.json")!)

    /// `XCTAssertNoThrow` 可用于獲取有關(guān)拋出的額外上下文
    XCTAssertNoThrow(try JSONDecoder().decode(User.self, from: jsonData))
}

當在任何進一步的測試執(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 中運行單元測試

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

使用測試三角形

您可以使用前導三角形運行單個測試或一組測試：

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

重新運行最新的測試

使用以下命令重新運行上次運行測試：

? Control + ? Option + ? Command + G.

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

運行測試組合

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

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

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

使用搜索字段根據(jù)名稱搜索特定測試
僅顯示當前所選方案的測試。如果您有多個測試方案，這將很有用。
只顯示失敗的測試。這將幫助您快速找到失敗的測試。

在側(cè)邊欄中啟用覆蓋

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

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

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

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

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

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

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

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

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

最重要的是，100% 的覆蓋率可能會產(chǎn)生誤導。上面的單元測試示例覆蓋了所有方法，覆蓋率為 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ù)程序并運行新的單元測試來驗證修復(fù)程序是否有效。此技術(shù)比運行模擬器來驗證您的修復(fù)是否有效要快。

結(jié)論

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

分享名稱：Swift單元測試入門，你學會了嗎？
網(wǎng)站地址：http://m.fisionsoft.com.cn/article/ccichss.html