摘要：而且，構(gòu)造函數(shù)不應(yīng)該包含行為，所以沒有值得測(cè)試的東西。一旦一個(gè)被創(chuàng)建了，你測(cè)試它的不為空因?yàn)槟阒罉?gòu)造函數(shù)創(chuàng)建了一個(gè)新的并將它賦給了變量。現(xiàn)在為類的構(gòu)造函數(shù)編寫的測(cè)試出問題了，即便類運(yùn)行良好，但并沒有包括。

在研究了有關(guān)測(cè)試的相關(guān)內(nèi)容，發(fā)現(xiàn)有些被忽略掉的很明顯的問題。

從積極的方面來說，寫自動(dòng)化測(cè)試的優(yōu)勢(shì)如下:

使重構(gòu)更簡(jiǎn)單 —— 你可以自信的修改實(shí)現(xiàn)細(xì)節(jié)，而不用去觸及公有 API。

避免代碼惡化—— 惡化在什么時(shí)候發(fā)生？在你修改代碼的時(shí)候。

提供了可執(zhí)行的說明和文檔 ——   * 你在什么時(shí)候更想知道軟件實(shí)際上是如何工作的？在你想修改它們的時(shí)候

減少了創(chuàng)建軟件的時(shí)間 —— 怎么減少時(shí)間的？是通過更快速地修改你的代碼，出錯(cuò)時(shí)測(cè)試會(huì)自信地告訴你哪里出錯(cuò)了

降低了創(chuàng)建軟件的代價(jià) —— 好吧，時(shí)間就是金錢，我的朋友

其實(shí)上述優(yōu)勢(shì)最大的就是，當(dāng)我們需要優(yōu)化代碼，進(jìn)行修改時(shí)，會(huì)給予我們一種保障。所以在自動(dòng)化測(cè)試的支撐下，我們需要做的就比較簡(jiǎn)單了。

有 5 條被認(rèn)為是每個(gè)測(cè)試都應(yīng)該遵守的基本原則。便于記憶這 5 條規(guī)則的縮寫是: F.I.R.S.T.

測(cè)試應(yīng)該：

很快速(Fast) —— 測(cè)試應(yīng)該能夠被經(jīng)常執(zhí)行。

能隔離(Isolated) —— 測(cè)試本身不能依賴于外部因素或者其他測(cè)試的結(jié)果。

可重復(fù)(Repeatable) —— 每次運(yùn)行測(cè)試都應(yīng)該產(chǎn)生相同的結(jié)果。

帶自檢(Self-verifying) —— 測(cè)試應(yīng)該包括斷言，不需要人為干預(yù)。

夠及時(shí)(Timely) —— 測(cè)試應(yīng)該和生產(chǎn)代碼一同書寫。

不要測(cè)試私有方法

私有方法意味著私有。如果你感到有必要測(cè)試一個(gè)私有方法，那么那個(gè)私有方法一定含有概念性錯(cuò)誤，通常是作為私有方法，它做的太多了， 從而違背了單一職責(zé)原則

如果僅僅為了測(cè)試，就讓私有方法變?yōu)楣?，那么就?huì)改變方法的私有性，會(huì)有被其他類調(diào)用的風(fēng)險(xiǎn)。那么應(yīng)該該如何去做呢。

通過這個(gè)類的公有 API。永遠(yuǎn)通過公有 API 測(cè)試你的代碼。程序的公有 API 定義了一個(gè)約定，它是一組關(guān)于你的程序?qū)?yīng)于不同輸入時(shí)定義良好的一組期望。私有 API (私有方法或者整個(gè)類) 并沒有定義約定，并且可以不經(jīng)通知自行修改，所以你的測(cè)試 (或者你的同事) 不能依賴于它們。

通過這種方法測(cè)試你的私有方法，你可以自由地修改你的 (真正的) 私有代碼，并且通過劃分成只做一件事情，并經(jīng)過正確測(cè)試的小的類，來提升代碼的設(shè)計(jì)。

不要Stub 私有方法

Stub 私有方法和測(cè)試私有方法具有相同的危害，更重要的是，stub 私有方法將會(huì)使程序難以調(diào)試。

同樣，當(dāng)我們 stub 一個(gè)方法的時(shí)候，我們必須依據(jù)它做出的約定來進(jìn)行。但是私有方法沒有指定的約定的 —— 畢竟，這也是為什么它們是私有的原因。由于私有方法的行為可以不經(jīng)通知自行修改，你的 stub 可能與實(shí)際情況背道而馳，但是你的測(cè)試仍然會(huì)通過。這是多么的可怕啊，讓我們來看一個(gè)例子：

今天：一個(gè)類的公有方法依賴于該類的一個(gè)私有方法。這個(gè)私有方法 foo 永遠(yuǎn)不會(huì)返回空。為公有方法編寫的測(cè)試為了方便起見，我們 stub 出了私有方法。當(dāng) stub foo 方法的時(shí)候，你永遠(yuǎn)不會(huì)考慮到 foo 返回為空的情況，因?yàn)楝F(xiàn)在這種情況永遠(yuǎn)不會(huì)發(fā)生。

明天：這個(gè)私有方法被修改了，現(xiàn)在它返回空了。它是一個(gè)私有方法，所以這沒什么問題。為公有方法編寫的測(cè)試不會(huì)相應(yīng)地被修改 (“我正在修改一個(gè)私有方法，所以我為什么要更新我的測(cè)試？”)。公有方法現(xiàn)在在私有方法返回空的情況下會(huì)出錯(cuò)，但是測(cè)試仍然會(huì)通過！

不要 Stub 外部庫

第三方代碼不應(yīng)該在你的測(cè)試中直接出現(xiàn)。

今天：你的網(wǎng)絡(luò)部分的代碼依賴于著名的 HTTP 庫 LSNetworking.為了避免使用實(shí)際的網(wǎng)絡(luò) (為了讓你的測(cè)試更快速更可信)，你 stub 了那個(gè)庫中的方法 -[LSNetworking makeGETrequest:]，沒有通過實(shí)際的網(wǎng)絡(luò)合適地替代了它的行為 (它通過一個(gè)封裝好的響應(yīng)調(diào)用了執(zhí)行成功的回調(diào))。

明天：你需要使用一個(gè)替代品來取代 LSNetworking (可能是 LSNetworking 已經(jīng)不再維護(hù)或者是你需要換成一個(gè)更先進(jìn)的庫，因?yàn)樗泻芏嗄阈枰男绿匦缘鹊?。這是一次重構(gòu)，所以你不應(yīng)該修改測(cè)試。你替換了庫。你的測(cè)試會(huì)失敗，因?yàn)橐蕾嚨木W(wǎng)絡(luò)沒有被 stub (-[LSNetworking makeGETrequest:]不會(huì)被調(diào)用)。

應(yīng)該做什么：測(cè)試中，依靠 stubbing 傘 (umbrella stubbing) 來替代那個(gè)庫的全部功能。

stubbing 傘 (一個(gè)我剛剛發(fā)明的術(shù)語) 包括了對(duì)于所有你的代碼可能用到的方式 -- 不管事現(xiàn)在還是將來 -- 的 stub。它們可以通過良好聲明的 API 完成一些任務(wù)，而不去關(guān)心實(shí)現(xiàn)的細(xì)節(jié)。

不要測(cè)試構(gòu)造函數(shù)

構(gòu)造函數(shù)定義的是實(shí)現(xiàn)細(xì)節(jié)，你不應(yīng)該測(cè)試構(gòu)造函數(shù)，這是因?yàn)槲覀冋J(rèn)同測(cè)試應(yīng)該與實(shí)現(xiàn)細(xì)節(jié)解耦這一觀點(diǎn)。而且，構(gòu)造函數(shù)不應(yīng)該包含行為，所以沒有值得測(cè)試的東西。

今天：你有一個(gè) Car 類，并包含一個(gè)構(gòu)造函數(shù)。一旦一個(gè) Car 被創(chuàng)建了，你測(cè)試它的 Engine 不為空 (因?yàn)槟阒罉?gòu)造函數(shù)創(chuàng)建了一個(gè)新的 Engine 并將它賦給了變量 _engine)。

明天：Engine 類創(chuàng)建起來變得代價(jià)很高，所以你決定使用延遲初始化 (lazily initialize)，在第一次調(diào)用 Engine 的 getter 方法時(shí)才初始化 Engine (這是很好的)。 現(xiàn)在為 Car 類的構(gòu)造函數(shù)編寫的測(cè)試出問題了，即便 Car 類運(yùn)行良好，但 Car 并沒有包括 Engine。另一個(gè)可能是你的測(cè)試不會(huì)失敗，因?yàn)闇y(cè)試包含 Engine 的 Car 類會(huì)觸發(fā) Engine 的延遲加載。所以我的問題是：為什么還要測(cè)試？

Given / When / Then模式
我們可以根據(jù) Given-When-Then 模式來組織我們的測(cè)試用例，將測(cè)試用例拆分成三個(gè)部分。

在 given 部分里，通過創(chuàng)建模型對(duì)象或?qū)⒈粶y(cè)試的系統(tǒng)設(shè)置到指定的狀態(tài)，來設(shè)定測(cè)試環(huán)境。when 這部分包含了我們要測(cè)試的代碼。在大部分情況，這里只有一個(gè)方法調(diào)用。在 then 這部分中 ，我們需要檢查我們行為的結(jié)果：是否得到了我們期望的結(jié)果？對(duì)象是否有改變？這部分主要包括一些斷言。簡(jiǎn)單一點(diǎn)來講就是，設(shè)定環(huán)境、調(diào)用方法、檢測(cè)結(jié)果。

簡(jiǎn)單的例子看起來是這個(gè)樣子的：

- (void)testThatItDoesURLEncoding
{
    // given
    NSString *searchQuery = @"$content$amp;?@";
    HTTPRequest *request = [HTTPRequest requestWithURL:@"/search?q=%@", searchQuery];

    // when
    NSString *encodedURL = request.URL;

    // then
    XCTAssertEqualObjects(encodedURL, @"/search?q=%24%26%3F%40");
}

這種簡(jiǎn)單的模式使我們能夠更容易地書寫和理解這些測(cè)試用例，因?yàn)樗鼈兌甲裱送瑯拥哪Ｊ?。為了更快地瀏覽，我們甚至?xí)诿總€(gè)部分的代碼上寫上 “given”，“when”，“then” 的注釋。通過這種方式，這個(gè)方法就能很快被理解。

Mock

在iOS測(cè)試中的mock測(cè)試框架可以采用OCMock。

我們用 mock 來管理一個(gè)對(duì)象的所有依賴項(xiàng)。通過這個(gè)方式，我們可以測(cè)試這個(gè)類在隔離情況下的行為。但是這里有個(gè)明顯的缺點(diǎn)，那就是當(dāng)我們修改了一個(gè)類后，其他依賴于這個(gè)類的類的單元測(cè)試不能自動(dòng)失敗。但是關(guān)于這一點(diǎn)我們可以通過集成測(cè)試來補(bǔ)救，因?yàn)樗梢詼y(cè)試所有的類。

我們不應(yīng)該‘過度mock’，也就是說，去 mock 除了被測(cè)試的對(duì)象的其他對(duì)象這樣的習(xí)慣是要盡量避免的。當(dāng)我們剛開始的時(shí)候，我們經(jīng)常會(huì)這樣做，我們甚至?xí)?mock 那些簡(jiǎn)單到可以作為方法參數(shù)的對(duì)象?，F(xiàn)在我們使用了不少真實(shí)的對(duì)象，而不是 mock 它們。

我們需要花時(shí)間編寫和維護(hù)它們。我們可以證明這種投資有回報(bào)的唯一方法就是我們期望節(jié)省時(shí)間。將實(shí)現(xiàn)細(xì)節(jié)和測(cè)試耦合在一起會(huì)減少測(cè)試帶來的回報(bào)，使得那些投資變得不合算，甚至在某些情況下變得一文不值。

在編寫測(cè)試、重構(gòu)以及修改系統(tǒng)行為的時(shí)候，檢查你的測(cè)試在面對(duì)錯(cuò)誤的原因時(shí)是失敗還是通過，然后退一步問問自己，那些測(cè)試是否能夠最大化你投資的成果

測(cè)試代碼量會(huì)比被測(cè)試代碼還要多

目前為止，我們的編碼庫已經(jīng)縱橫 190 個(gè)文件和 18,000 行代碼，達(dá)到了 544 kB。我們測(cè)試部分的代碼現(xiàn)在差不多有1,200 kB，大概有被測(cè)試代碼的兩倍。雖然我們還沒有完全結(jié)束這個(gè)項(xiàng)目，但是已經(jīng)接近尾聲。

引用文章
Real-World Testing with XCTest
Bad Testing Practices