iOS 單元測試之常用框架 OCMock 詳解

一、單元測試

1.1 單元測試的必要性

測試驅動開發並不是一個很新鮮的概念了。在日常開發中，很多時候需要測試，但是這種輸出是必須在點選一系列按鈕之後才能在螢幕上顯示出來的東西。測試的時候，往往是用模擬器一次一次的從頭開始啟動 app，然後定位到自己所在模組的程式，做一系列的點選操作，然後檢視結果是否符合自己預期。

這種行為無疑是對時間的巨大浪費。於是有很多資深工程師們發現，我們是可以在程式碼中構造一個類似的場景，然後在程式碼中呼叫我們之前想要檢查的程式碼，並將執行結果和設想結果在程式中進行比較，如果一致，則說明我們的程式碼沒有問題，由此就產生了單元測試。

1.2 單元測試的目的

單元測試的主要目的是發現模組內部邏輯、語法、演演算法和功能錯誤。

單元測試主要是基於白盒測試驗證以下問題：

驗證程式碼與設計相符度。
發現設計和需求中存在錯誤。
發現在編碼過程中引入的錯誤。

單元測試關注的重點有以下部分：

獨立路徑-對於基本執行路徑和迴圈進行測試，可能的錯誤有：

不同資料型別的比較。
「差1錯」，即可能多回圈或少迴圈一次。
錯誤或不可能的終止條件。
不適當的修改了迴圈變數。

區域性資料結構-單元的區域性資料結構是最常見的錯誤來源，應設計測試用例以檢查可能的錯誤：

不一致的資料型別。
檢查不正確或不一致的資料型別。

錯誤處理-比較完善的單元設計要能預見出錯的條件，並設定適當的錯誤處理，以便在程式出錯時，能對錯誤重新做安排，保證期邏輯上的正確性：

出錯的描述難以理解。
顯示的錯誤與實際的錯誤不符。
對錯誤條件的處理不正確。

邊界條件-邊界上出現錯誤是最常見的錯誤現象：

取最大最小值發生錯誤。
控制流中的大於、小於這些比較值常出現錯誤。

單元介面-介面實際上就是輸入和輸出對應關係的集合，要對單元進行動態測試無非就是給這個單元一個輸入，然後檢查輸出是否和預期一致。如果資料不能正常輸入和輸出，單元測試就無從談起，因此需要對單元介面進行如下的測試：

被測單元的輸入、輸出在個數、屬性、順序是否和詳細設計中的描述一致。
是否修改了只做輸入用的形式引數。
約束條件是否通過形式引數來傳送。

1.3 單元測試依賴的兩個主要框架

OCUnit（即用 XCTest 進行測試）其實就是蘋果自帶的測試框架，主要是斷言使用，由於使用簡單本次文章不過多介紹。

OCMock主要功能是模擬某個方法或者屬性的返回值，你可能會疑惑為什麼要這樣做?使用模型生成的模型物件，再傳進去不就可以了？答案是可以的，但是有特殊的情況，比如一些不容易構造或不容易獲取的物件，此時你可以建立一個虛擬的物件來完成測試。實現思想是根據要mock的物件的class來建立一個對應的物件，並且設定好該物件的屬性和呼叫預定方法後的動作（例如返回一個值，呼叫程式碼塊，傳送訊息等等），然後將其記錄到一個陣列中，接下來開發者主動呼叫該方法，最後做一個verify（驗證），從而判斷該方法是否被呼叫，或者呼叫過程中是否丟擲異常等。在單元測試開發中使用更多難點的也是對OCMock的使用方式不明確，本次文章主要講的就是這個 OCMock 的整合和使用方法。

二、OCMock 的整合與使用

2.1 OCMock 的整合方式

專案整合 OCMock 第三方庫，這個使用 pod 工具直接安裝OCMock框架即可。若使用 iBiu 工具安裝 OCMock 庫需在 podfile 檔案同級建立 Podfile.custom。

使用普通的 pod 檔案相同格式新增 OCmock 如下：

source 'https://github.com/CocoaPods/Specs.git'
pod 'OCMock'

2.2 OCMock 的使用方法

（一）置換方法(存根)：告訴 mock 物件,當 someMethod 被呼叫,返回什麼值

呼叫方式：

d jalopy = [OCMock mockForClass[Car class]];
OCMStub([jalopy goFaster:[OCMArg any] units:@"kph"]).andReturn(@"75kph");

使用場景：

1．驗證 A 方法時，A 方法內部使用 B 方法的返回值但是 B 方法內部邏輯比較複雜，這時需要使用 stub 方法去存根 B 方法的返回值。程式碼實現類似下面程式碼實現固定 funcB 的返回值，做到在不影響原始碼的條件下，獲取滿足測試需要的引數。

方法進行存根前

- (NSString *)getOtherTimeStrWithString:(NSString *)formatTime{
    NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
    [formatter setDateStyle:NSDateFormatterMediumStyle];
    [formatter setTimeStyle:NSDateFormatterShortStyle];
    [formatter setDateFormat:@"YYYY-MM-dd HH:mm:ss"]; //(@"YYYY-MM-dd hh:mm:ss") ----------設定你想要的格式,hh與HH的區別:分別表示12小時制,24小時制
    //設定時區選擇北京時間
    NSTimeZone* timeZone = [NSTimeZone timeZoneWithName:@"Asia/Beijing"];
    [formatter setTimeZone:timeZone];
    NSDate* date = [formatter dateFromString:formatTime]; //------------將字串按formatter轉成nsdate
    //時間轉時間戳的方法:
    NSInteger timeSp = [[NSNumber numberWithDouble:[date timeIntervalSince1970]] integerValue] * 1000;
    return [NSString stringWithFormat:@"%ld",(long)timeSp];
}

使用stub(mockObject getOtherTimeStrWithString).andReturn(@"1000")存根後類似於以下效果

- (NSString *)getOtherTimeStrWithString:(NSString *)formatTime{
    
    return @"1000";
    
    NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
    [formatter setDateStyle:NSDateFormatterMediumStyle];
    [formatter setTimeStyle:NSDateFormatterShortStyle];
    [formatter setDateFormat:@"YYYY-MM-dd HH:mm:ss"]; //(@"YYYY-MM-dd hh:mm:ss") ----------設定你想要的格式,hh與HH的區別:分別表示12小時制,24小時制
    //設定時區選擇北京時間
    NSTimeZone* timeZone = [NSTimeZone timeZoneWithName:@"Asia/Beijing"];
    [formatter setTimeZone:timeZone];
    NSDate* date = [formatter dateFromString:formatTime]; //------------將字串按formatter轉成nsdate
    //時間轉時間戳的方法:
    NSInteger timeSp = [[NSNumber numberWithDouble:[date timeIntervalSince1970]] integerValue] * 1000;
    return [NSString stringWithFormat:@"%ld",(long)timeSp];
}

2．程式碼正常流程經過測試已經很健壯了，但是一些錯誤的流程並不容易發現但是是可能存在的，例如邊緣值資料，單元測試中可以使用存根對資料進行模擬，測試程式碼在特殊資料情況下的執行情況。

注：stub()也可以不設定返回值，驗證可行，猜測可能是返回的nil或者void，所以不帶返回值的方法也可以進行方法存根。

（二）生成 Mock 物件，目前有三種方式。

通過對Person類的talk方法進行測試舉例，其中也涉及Men類以及Animaiton類，以下是三個類的相關原始碼。

Person類

@interface Person()
@property(nonatomic,strong)Men *men;
@end


@implementation Person
-(void)talk:(NSString *)str
{
    [self.men logstr:str];
    [Animaiton logstr:str];
    
}
@end

Men類

@implementation Men
-(NSString *)logstr:(NSString *)str
{
    NSLog(@"%@",str);
    return str;
}
@end

Animaiton類

@implementation Animaiton
+(NSString *)logstr:(NSString *)str
{
    NSLog(@"%@",str);
    return str;
}
-(NSString *)logstr:(NSString *)str
{
    NSLog(@"%@",str);
    return str;
}
@end

對talk方法進行單測時需要對person類進行mock，以下是通過三種不同的方式生成mock物件，對三種方式的呼叫方法，使用場景都做了介紹，最後對每種方式的優缺點也做了一個表格方便區別。

Nice Mock

NiceMock 建立的 mock 物件在進行方法測試時會優先呼叫實體方法，若未找到實體方法，會繼續呼叫同名的類方法。因此該方法可以用來生成mock物件去測試類方法也可以測試物件方法。

使用方式：

- (void)testTalkNiceMock {
    id mockA = OCMClassMock([Men class]);
    Person *person1 = [Person new];
    person1.men = mockA;
    [person1 talk:@"123"];
    OCMVerify([mockA logstr:[OCMArg any]]);
}

使用場景：

Nice mock 是比較友好的，當一個沒有存根的方法被呼叫時他不會引起一個異常會驗證通過。如果你不想自己對很多的方法進行存根，那麼使用 nice mock。在上方的舉例中mockA呼叫testTalkNiceMock時，Men類中的+(NSString *)logstr:(NSString *)str不會執行列印操作。在呼叫過程中因為同時存在同名的logstr：類方法和實體方法，會優先呼叫實體方法。

Strict Mock

使用方式：

測試case如下，mockA是Strict Mock生成要呼叫testTalkStrictMock方法，則Mock生成要呼叫testTalkStrictMock方法則該方法要使用stub進行存根,否則最後的OCMVerifyAll（mockA）就會丟擲異常。

- (void)testTalkStrictMock {
    id mockA = OCMStrictClassMock([Person class]);
    OCMStub([mockA talk:@"123"]);
    [mockA talk:@"123"];
    OCMVerifyAll(mockA);
}

使用場景：

這種方式建立的 mock 物件，如果呼叫未 stub（stub 代表存根）的方法，會丟擲一個異常。這需要保證在 mock 的生命週期中每一個獨立呼叫的方法都是被存根的，這種方法使用比較嚴格，很少使用。

Partial Mock

這樣建立的物件在呼叫方法時:如果方法被 stub,呼叫 stub 後的方法，如果方法沒有被 stub,呼叫原來的物件的方法，該方法有限制只能 mock 範例物件。

使用方式：

- (void)testTalkPartialMock {
    id mockA = OCMPartialMock([Men new]);
    Person *person1 = [Person new];
    person1.men = mockA;
    [person1 talk:@"123"];
    OCMVerify([mockA logstr:[OCMArg any]]);
}

使用場景：

當呼叫一個沒有被存根的方法時，會呼叫實際物件的該方法。當不能很好的存根一個類的方法時，該技術是非常有用的。呼叫testTalkPartialMock時Men類中的+(NSString *)logstr:(NSString *)str會執行列印操作。

三種方式的差異表格：

（三）驗證方法的呼叫

呼叫方式：

OCMVerify([mock someMethod]);
OCMVerify(never(),    [mock doStuff]); //從沒被呼叫
OCMVerify(times(n),   [mock doStuff]);   //呼叫了N次
OCMVerify(atLeast(n), [mock doStuff]);  //最少被呼叫了N次
OCMVerify(atMost(n),  [mock doStuff]);

使用場景：

在單元測試中可以驗證某個方法是否執行，以及執行了幾次。

延時驗證呼叫：

OCMVerifyAllWithDelay(mock, aDelay);

使用場景：該功能用於等待非同步操作會比較多，其中aDelay為預期最長等待時間。

（四）新增預期

呼叫方式：

準備資料：

NSDictionary *info = @{@"name": @"momo"};
id mock = OCMClassMock([MOOCMockDemo class]);

新增預期：

OCMExpect([mock handleLoadSuccessWithPerson:[OCMArg any]]);

可以預期不執行：

OCMReject([mock handleLoadFailWithPerson:[OCMArg any]]);

可以驗證引數：

// 預期 + 引數驗證
OCMExpect([mock handleLoadSuccessWithPerson:[OCMArg checkWithBlock:^BOOL(id obj) {
    MOPerson *person = (MOPerson *)obj;
    return [person.name isEqualToString:@"momo"];
}]]);

可以預期執行順序：

// 預期下列方法順序執行
[mock setExpectationOrderMatters:YES];
OCMExpect([mock handleLoadSuccessWithPerson:[OCMArg any]]);
OCMExpect([mock showError:NO]);

可以忽略引數(預期方法執行時)：

OCMExpect([mock showError:YES]).ignoringNonObjectArgs; // 忽視引數

執行：

[MOOCMockDemo handleLoadFinished:info];

斷言：

OCMVerifyAll(mock);

可以延遲斷言：

OCMVerifyAllWithDelay(mock, 1); // 支援延遲驗證

最後的 OCMVerifyAll 會驗證前面的期望是否有效，只要有一個沒呼叫，就會出錯。

（五）引數約束

呼叫方式：

OCMStub([mock someMethodWithAnArgument:[OCMArg any]])
OCMStub([mock someMethodWithPointerArgument:[OCMArg anyPointer]])
OCMStub([mock someMethodWithSelectorArgument:[OCMArg anySelector]])

使用場景：在使用 OCMVerify（）方法驗證某個方法是否呼叫是使用,單元測試會驗證方法引數是否一致，如果不一致就是提示驗證失敗，此時如果只關注方法呼叫，並不關注引數即可使用[OCMArg any]傳參。

（六）網路介面的模擬

顧名思義可以 mock 網路介面的資料返回，測試不同資料下程式碼的走向以及準確性。

呼叫方式：

id mockManager = OCMClassMock([JDStoreNetwork class]);
[orderListVc setComponentsNet:mockManager];
[OCMStub([mockManager startWithSetup:[OCMArg any] didFinish:[OCMArg any] didCancel:[OCMArg any]]) andDo:^(NSInvocation *invocation) {   


    void (^successBlock)(id components,NSError *error) = nil;   
    
    [invocation getArgument:&successBlock atIndex:3];  
    
    successBlock(@{@"code":@"1",@"resultCode":@"1",@"value":@{@"showOrderSearch":@"NO"}},nil);
    }];

以上就是在呼叫 setComponentsNet 方法內部呼叫了介面，該方法就可以在呼叫介面後模擬需要的返回資料，successBlock 中的就是返回的測試資料。本方式是通過獲取介面呼叫的方法簽名，獲取 successBlock 成功回撥傳參並手動呼叫。同樣可以模擬介面失敗的情況，只需獲取到簽名中的對應的失敗回撥就可以實現了。

使用場景：書寫單元測試方法時涉及網路介面的模擬，通過該方式 mock 介面返回結果。

（七）恢復類

置換類方法後,可以將類恢復到原來的狀態,通過呼叫 stopMocking 來完成。

呼叫方式：

id classMock = OCMClassMock([SomeClass class]);
/* do stuff */
[classMock stopMocking];

使用場景：

正常對範例物件置換後，mock 物件釋放後會自動呼叫 stopMocking，但是新增到類方法上的 mock 物件會跨越了多個測試,mock 的類物件在置換後不會 deallocated,需要手動來取消這個 mock 關係。

（八）觀察者模擬-建立一個接受通知的範例

呼叫方式：

- (void)testPostNotification {   
Person *person1 = [[Person alloc] init];   
id observerMock = OCMObserverMock();   
//給通知中心設定觀察者    
[[NSNotificationCenter defaultCenter] addMockObserver: observerMock name:@"name" object:nil];    
//設定觀察期望    
[[observerMock expect] notificationWithName:@"name" object:[OCMArg any]];    //呼叫要驗證的方法    
[person1 methodWithPostNotification];    
[[NSNotificationCenter defaultCenter] removeObserver:observerMock];    
// 呼叫驗證   
OCMVerifyAll(observerMock);}

使用場景：

建立一個 mock 物件,可以用來觀察通知。mock 必須註冊以接收通知。

（九）mock協定

呼叫方式：

id protocolMock = OCMProtocolMock(@protocol(SomeProtocol));
/*嚴格的協定*/
id classMock = OCMStrictClassMock([SomeClass class]);
id protocolMock = OCMStrictProtocolMock(@protocol(SomeProtocol));
id protocolMock = OCMProtocolMock(@protocol(SomeProtocol));
/*嚴格的協定*/
id classMock = OCMStrictClassMock([SomeClass class]);
id protocolMock = OCMStrictProtocolMock(@protocol(SomeProtocol));

呼叫場景：當需要建立一個範例，讓其具有協定的所定義的功能時使用。

2.3 mock使用限制

對於同個方法，先stub後expect是不行的：因為先stub的話，所有的呼叫都會變成stub，這樣子即使過程呼叫該方法，最後OCMVerifyAll驗證也會失敗；解決的辦法是，在OCMExpect上順便stub，比如：OCMExpect([mock someMethod]).andReturn(@"a string")，或者將stub置於expect之後。

部分模擬不適用於某些類：如NSString和NSDate，這些」toll-free bridged」的類，否則會丟擲異常。

某些方法不能stub：如：init、class、methodSignatureForSelector、forwardInvocation這些。

NSString與NSArray的類方法不能stub，否則無效。

NSObject的方法呼叫不能驗證，除非在子類中重寫。

蘋果核心類的私有方法呼叫不能被驗證，如以_開頭的方法。

延時驗證方法呼叫不支援，暫時只支援期望-執行-驗證模式的延時驗證。

OCMock不支援多執行緒。

三、最後

希望這篇文章和例子已經陳述清楚了一些 OCMock 最通用的用法。OCMock 站點：http://ocmock.org/features/ 是一個最好的學習 OCMock 的地方。mock 是單調的但是對於一個應用程式卻是必須的。如果一個方法很難用 mock 來測試，這個跡象表明你的設計需要重新考慮了。

參考連結：

OCMock 官網：https://ocmock.org/features/

OCMock3 參考：https://www.cnblogs.com/xilifeng/p/4690280.html

iOS測試系列：http://blog.oneinbest.com/2017/07/27/iOS測試系列-三-OCMock的使用/

作者：京東零售王中文

來源：京東雲開發者社群