摘要：測試期間，模擬對象會記錄你發送給它的每一條消息。這種使用模擬對象的模式叫做謙卑對象。這意味著需要所有的文物清單，并對這些對象做一些測試，而我們所做的是使方法與庫存對象進行溝通。這個測試類也會影響文物數據模型的設計。

測試驅動開發（TDD）中，開發者經常使用模擬對象進行系統設計，模擬對象到底是什么呢？部分模擬對象和全部模擬對象又是什么呢？模擬對象真的讓人又愛又恨嗎？讓我們以Objective-C測試框架OCMock來探個究竟。

模擬對象可以解決兩種問題。第一種是（它們也是因此而提出的）用于設計測試驅動開發的測試類。想象一下，你已經完成了第一個測試，并知道了一些關于第一個類的API的信息。你的測試調用了新類的方法，你知道，應該從它們協作者之一種抓取一些信息。問題是，協作者尚不存在，而你又不想放棄這個已經設計出來的并開始測試的類。

此時，你可以創建一個模擬對象代表這個尚未“出生”的協作者。你可以設定你想要通過該“協作者”測試調用對象的期望值，而且，如果需要的話，還可以返回一個可以測試控制的值。你的測試可以驗證你所期望調用的方法是否真的被調用了，如果沒有，則測試失敗。

在這種情況下，模擬對象就像一臺VCR，只是沒有上世紀八十年代的矮胖的造型和易受損的磁帶。測試期間，模擬對象會記錄你發送給它的每一條消息。然后，可以通過重放與消息列表做比較來看是不是你所需要的。就像用VCR，如果你想要看的是小精靈2(Gremlins 2)，但是記錄的卻是上半年的新聞和歡樂酒店(Cheers)，這就讓人較為失望。

關鍵的部分是，你實際上并不需要建立真正的協作對象。事實上，你完全不需要關心它是怎么實施的。唯一需要關注的是它需要返回的消息，這樣就可以驗證他們是否被發送了。實際上，模擬對象可以讓你覺得說，“我知道，在某些時候，我會考慮這一點，但我不希望因此而分心。” 對于測試驅動開發者，這就像一個待辦事項清單一樣清晰。

讓我們來看一個例子。假設書呆子Ranch發現了市場上對博物館庫存管理App的需求。通常博物館收藏了大量的文物，他們需要了解所有的庫存，并能按主題，國家，年代等在畫廊組織展覽。關于庫存的需求類似如下：

  
作為策展人，我想知道所有需要展出的文物，這樣我就可以給我的游客們講故事了。

我會寫一個可以提供一個所有文物的清單的庫存類用來測試。當然，磁盤上還有其他類也存儲了所有的文物，但是我不關心他們是如何工作的，我只要創建一個庫存接口的模擬對象。我的測試類如下：

@implementation BNRMuseumInventoryTests

- (void)testArtefactsAreRetrievedFromTheStore

{

    //Assemble

    id store = [OCMockObject mockForProtocol:@protocol(BNRInventoryStore)];

    BNRMuseumInventory *inventory = [[BNRMuseumInventory alloc] initWithStore:store];

    NSArray *expectedArtefacts = @[@"An artefact"];

    [[[store expect] andReturn:expectedArtefacts] fetchAllArtefacts];

    //Act

    NSArray *allArtefacts = [inventory allArtefacts];

    //Assert

    XCTAssertEqualObjects(allArtefacts, expectedArtefacts);

    [store verify];

}

@end

為了讓這個類編譯通過，我需要創建BNRMuseumInventory類和它的initWithStore：和allArtefacts方法。

@interface BNRMuseumInventory : NSObject

- (id)initWithStore:(id )store;

- (NSArray *)allArtefacts;

@end

@implementation BNRMuseumInventory

- (id)initWithStore:(id )store

{

return nil;

}

- (NSArray *)allArtefacts

{

return nil;

}

@end

我還要定義BNRInventoryStore協議及其-fetchAllArtefacts方法，但我現在還不需要實現它們。為什么要我將它定義為一個協議，而不是另一個類？是為了提高靈活性：我知道我想發送給BNRInventoryStore的消息，但我并不需要關心它是如何處理這些消息的。使用協議能讓我靈活的處理實現存儲的方法：只要它能響應我所關心的消息，它可以是任何類型的類。

@protocol BNRInventoryStore 

- (NSArray *)fetchAllArtefacts;

@end

現在有足夠的信息讓編譯器來編譯和運行測試，但它還是不能通過。

Test Case "-[BNRMuseumInventoryTests testArtefactsAreRetrievedFromTheStore]" started.

/Users/leeg/BNRMuseumInventory/BNRMuseumInventory Tests/BNRMuseumInventoryTests.m:91: error: -[BNRMuseumInventoryTests testArtefactsAreRetrievedFromTheStore] : ((allArtefacts) equal to (expectedArtefacts)) failed: ("(null)") is not equal to ("(

"An artefact"

)")

:0: error: -[BNRMuseumInventoryTests testArtefactsAreRetrievedFromTheStore] : OCMockObject[BNRInventoryStore]: expected method was not invoked: fetchAllArtefacts

// snip more output

在測試中斷言檢測到期待的文物集合并未返回，fetchAllArtefacts方法沒有被調用，模擬對象驗證失敗。只有修復這兩個問題，我們才可以通過測試。

@implementation BNRMuseumInventory

{

id  _store;

}

- (id)initWithStore:(id )store

{

self = [super init];

if (self)

{

_store = store;

}

return self;

}

- (NSArray *)allArtefacts

{

return [_store fetchAllArtefacts];

}

@end

第二種使用模擬對象的方法是使用外部代碼，如蘋果的框架或第三方庫，進行一體化。模擬對象可以簡化使用框架所帶來的復雜性，因為測試并不需要搭建一個成熟的環境，只需確保我們的應用程序能連接到該環境中的一小部分。這種使用模擬對象的模式叫做謙卑對象（Humble Object）。

繼續VCR的比喻，我們并沒有設計一個與框架交互的類，但我們要檢查我們是否遵守了他們規定的規則。就像了你買了一臺VHS錄像機，但你不需要知道磁帶的類型，你只能使用VHS錄像帶，因為這是廠家規定的。同樣的，我們可以告訴我們的模擬對象，期望值是VHS磁帶，所以如果我們給它一個錄像帶Betamax，測試將會失敗。

回到我們的博物館例子中，當應用程序啟動時，首先應該看到的是博物館所有文物的清單，這可以使用UIKit設置窗口的根視圖控制器來實現。但是要設置整個窗口的測試環境，會非常慢且復雜，所以我們用一個模擬對象替換窗口。

- (void)testFirstScreenIsTheListOfAllArtefacts

{

BNRAppDelegate *appDelegate = [[BNRAppDelegate alloc] init];

id window = [OCMockObject mockForClass:[UIWindow class]];

appDelegate.window = window;

[[window expect] setRootViewController:[OCMArg checkWithBlock:^(id viewController) {

return [viewController isKindOfClass:[BNRAllArtefactsTableViewController class]];

}]];

[appDelegate application:nil didFinishLaunchingWithOptions:nil];

[window verify];

}

@end

為了使這個測試通過，須實現應用程序的委托方法。

@implementation BNRAppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)options

{

self.window.rootViewController = [[BNRAllArtefactsTableViewController alloc] initWithStyle:UITableViewStyleGrouped];
return YES;

}

@end

該例子中，還有另外一個需求：當加載一個UIKit的應用程序時：包含初始視圖控制器的窗口必須是主要且可見的。我們可以添加一個測試表達這一要求。請注意，由于這個測試和之前的測試使用的是相同的對象，該構造函數可以被分解成一個setup方法。

@implementation BNRAppDelegateTests

{

BNRAppDelegate *_appDelegate;

id _window;

}

- (void)setUp

{

_appDelegate = [[BNRAppDelegate alloc] init];

_window = [OCMockObject mockForClass:[UIWindow class]];

appDelegate.window = _window;

}

- (void)testWindowIsMadeKeyAndVisible

{

[[_window expect] makeKeyAndVisible];

[_appDelegate application:nil didFinishLaunchingWithOptions:nil];

[_window verify];

}

- (void)testFirstScreenIsTheListOfArtefacts

{

[[_window expect] setRootViewController:[OCMArg checkWithBlock:^(id viewController) {

return [viewController isKindOfClass:[BNRAllArtefactsTableViewController class]];

}];

[_appDelegate application:nil didFinishLaunchingWithOptions:nil];

[_window verify];

}

@end

現在我們遇到了一個棘手的問題。新測試失敗的原因有兩個：預期的makeKeyAndVisible消息沒有被發送，卻正在發送一個意外的消息setRootViewController：.在 [BNRAppDelegate application：didFinishLaunchingWithOptions：]方法中添加 -makeKeyAndVisible消息 -表示兩個測試都失敗了，因為模擬窗口對象在每個測試都接收了一個未期待的方法。

完全模擬可以解決這個問題。完全模擬對象可記錄它接收到的所有消息，就像一個普通的模擬消息對象，包括不期待的消息。這就像說，“我想記錄星際旅行的那個情節：航海者，但如果在這之前有天氣預報，我也不介意”，它忽略了額外的信息，并且不考慮導致測試失敗的消息。

我們可以在setUp方法中把這個測試的模擬窗口改成一個完全模擬。

- (void)setUp

{

_appDelegate = [[BNRAppDelegate alloc] init];

_window = [OCMockObject niceMockForClass:[UIWindow class]];

appDelegate.window = _window;

}

現在，它可以改變應用程序的委托，這樣兩個測試都可以通過。

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)options

{

self.window.rootViewController = [[BNRAllArtefactsTableViewController alloc] initWithStyle:UITableViewStyleGrouped];

[self.window makeKeyAndVisible];
return YES;

}

有時候，你并不需要用模擬取代所有對象的行為。你只是想消除一些依賴或復雜的行為，并在你要測試的方法使用其結果。你可以創建一個子類，并重寫復雜的方法，此時使用部分模擬會更容易。部分模擬作為真正的對象的代理，截取了部分消息，但是仍然可以使用那些沒有被替換的消息的實現方法。

再回到我們的博物館庫存的App例子中，策展人需要將文物的原產地作為篩選條件。這意味著需要所有的文物清單，并對這些對象做一些測試，而我們所做的是使allArtefacts方法與庫存對象進行溝通。但這并不是我們在本次測試需要關心的事情：我們要專注于篩選，且不重復我們在之前已經完成的測試工作。使用庫存對象的部分模擬就可以讓我們去掉樁對象的那部分。這個測試類也會影響文物數據模型的設計。

@implementation BNRMuseumInventoryTests

{

BNRMuseumInventory *_inventory; //created in -setUp

}

//...

- (void)testArtefactsCanBeFilteredByCountryOfOrigin

{

id romanPot = [OCMockObject mockForProtocol:@protocol(BNRArtefact)];

[[[romanPot stub] andReturn:@"Italy"] countryOfOrigin];

id greekPot = [OCMockObject mockForProtocol:@protocol(BNRArtefact)];

[[[greekPot stub] andReturn:@"Greece"] countryOfOrigin];

id partialInventory = [OCMockObject partialMockForObject:_inventory];

[[[partialInventory stub] andReturn:@[romanPot, greekPot]] allArtefacts];

NSArray *greekArtefacts = [partialInventory artefactsFromCountry:@"Greece"];

XCTAssertTrue([greekArtefacts containsObject:greekPot]);

XCTAssertFalse([greekArtefacts containsObject:romanPot]);

}

@end

在上面的測試中，我用OCMock的-stub方法，而不是-expect方法。該方法告訴模擬對象處理該消息并返回指定的值（如果有），但不設置該測試稍后需驗證的消息的期望值。我可以通過artefactsFromCountry的返回值來辨別代碼是否有用，我并不需要關心如何實現（但如果你擔心硬編碼的一些作弊行為，譬如：通常都會返回集合中的最后一個對象，你可以簡單地添加更多的測試）。

這個測試告訴我們一些關于BNRArtefact協議的事情。

- (NSString *)countryOfOrigin;

@end

現在就可以創建artfactsFromCountry：方法。

- (NSArray *)artefactsFromCountry:(NSString *)country

{

NSArray *artefacts = [self allArtefacts];

NSIndexSet *locationsOfMatchingArtefacts = [artefacts indexesOfObjectsPassingTest:^(id  anArtefact, NSUInteger idx, BOOL *stop){

return [[anArtefact countryOfOrigin] isEqualToString:country];

}];

return [artefacts objectsAtIndexes:locationsOfMatchingArtefacts];

}

當你構建應用程序的測試驅動時，模擬對象能幫助你集中注意力。他們讓你專注于你現在正在做的測試，同時推遲對你未創建對象的測試。他們讓你專注于你正在測試的對象的部分，忽略你已經測試過或尚未測試的東西。他們還讓你專注于你自己的代碼，用簡單的類代替復雜的框架類。

如果你由文中VCR想到了你家的那部錄音機，那它估計已經到了進博物館的年紀了，而我們剛剛寫的文物庫存管理應用程序，它會在那找到一個舒適的家。

原文 Making a Mockery with Mock Objects
翻譯 伯樂在線 - Stellar