Menu
Article

歡迎來到真實世界 - Unit Test for Core Data

Huang ShihTing

Huang ShihTing

• 20 min read

Introduction

Once an idea has taken hold of the brain it's almost impossible to eradicate. - Cobb
一旦某個想法掌握了你的腦袋，它將會變得難被鏟除。-Cobb

Inception(全面啟動)一直都是個人最愛的電影之一，劇情燒腦、世界觀完整、畫面夢幻，而且又是這種穿越虛實的題材，幾乎所有元素都深得我心。

進入夢境就電影來說不算太新的梗，Inception跟其它夢境電影不一樣的是，進入夢境有個更複雜的原因：要徹底改變某個人的想法。老梗電影如果進入某人的夢境，很有可能就只是要引出一些秘密，像是金庫密碼之類的(腦海中馬上浮現：左三、右二、左一)，但是在Inception裡，進入別人的夢境是為了要改變某人的想法，讓他乖乖地聽話做一些很蠢的事。這點其實非常的有趣，在生活中，的確有些想法根植在腦海中，久久揮之不去，就像被誰植入了思想一樣，比方說戈巴契夫頭髮最多、海珊最不愛打仗，到長大後我還是一直深信不移。

所以這跟我們今天的主題有甚麼關係呢？非常有關係！因為從上篇文章開始，內容就一直都圍繞著一個主題：我最喜歡的電影...阿不是，是如何在iOS上做乾淨的、與真實環境互相獨立的單元測試。

在上次介紹完Depedency Injection之後，想必大家應該都很了解如何在自己的模組裡，把現實環境抽掉，植入一個假的環境了。如果還不是很清楚Depedency Inject在測試上的應用，可以參考拙做：歡迎來到真實世界 - Unit Test for Networking(https://www.codementor.io/koromiko/unit-test-for-networking-ahdpdqr5k)。

接下來，我們會延續上次的主題，繼續來探討需要跟真實世界互動的元件的Unit Test。在這篇文章，我們主要研究的題目是：怎樣做Core Data的Unit Test。

Core Data是一個iOS上面資料結構的封裝，它把跟資料庫相關的邏輯都封裝起來，並且提供大量高階的方法，讓你盡量避免在儲存資料時，還需要把資料庫邏輯跟商業邏輯都寫在一起，讓存取資料變的更直觀。如果要順利地閱讀這篇文章，需要的背景知識就是Core Data的基本運作原理、Core Data的concurrency等。如果不太了解Core Data的運作，可以參考一些教學文章：

A Complete Core Data Application · objc.io(https://www.objc.io/issues/4-core-data/full-core-data-application)

An Introductory Core Data Tutorial - Cocoacasts(https://cocoacasts.com/core-data-tutorial/)

TL;DR

這篇文章會包含以下主題：

  • 使用NSPersistentContainer建置Core Data stack
  • 設定In-memory Persistent Store
  • 基本測試技巧：Fake、Stub
  • 在XCTestCase內做非同步的測試

Requirement

這篇文章中使用的開發環境為：

  • Swift 3
  • iOS 10
  • Xcode 8

因為我們會使用NSPersistentContainer來設定Core Data Stack，所以iOS 10是必要的。

Our task

今天我們的目標是要實做一個簡單的todo list系統，可以新增、讀取、修改、刪除(CRUD, create, read, update, delete) todo list，我們希望這個系統，可以在關掉app再打開之後，還能繼續記得上次修改的資料。沒錯，這個todo list app比腦袋還強！

所以我們的任務來了，我們需要一個系統可以：

  1. 新增一個Todo
  2. 取出所有Todo
  3. 刪除一個Todo
  4. 把暫存的資料推進persistent store

因為手機上資源有限，我們不希望每次存取都動到真的資料庫，而是要在真的有需要的時候，才把資料寫入資料庫，所以我們在設計這個系統的時候，會把儲存資料這件事抽出來（第4點)，讓它可以納入商業邏輯的考量之中，未來就可以視情況，看是要讓使用者按下儲存後才真的儲存，或是資料累積到一定的量才儲存。

Core Data在iOS 10之後，其實已經大幅簡化了設定難度，以往需要寫一大堆boilerplate的狀況已經不復見了，在使用上也不一定需要很深入的了解，就能夠做基本的操作。雖然話是這麼說沒錯，但如果能夠了解整個Core Data stack，還有各個元件互動的方式，對於設計模組跟寫測試還是有一定的幫助的，所以下面這個小節，會簡單提一下Core Data stack裡面有那些元件，還有這些元件是怎樣互動的。

Core Data stack

Core Data stack是整個Core Data的基本架構，描述Core Data在運作時，有那些元件，這些元件各自會有那些任務等等。

根據Apple的文件(https://developer.apple.com/library/content/documentation/DataManagement/Devpedia-CoreData/coreDataStack.html)，Core Data Stack分成下面幾個部份：

  • Managed Object Context (NSManagedObjectContext)，提供不同的運行環境給managed objects。
  • Persistent Store Coordinator (NSPersistentStoreCoordinator)，負責整合每個Data Stores。
  • Managed Object Model (NSManagedObjectModel)，負責描述資料的結構、長相等等。
  • Persistent Object Store，負責底層的資料庫寫入跟讀取等。

Core Data stack(https://developer.apple.com/library/content/documentation/DataManagement/Devpedia-CoreData/coreDataStack.html)

以往要設定好這個stack，需要寫非常多的code來個別設定。而在iOS 10之後，官方提供了一個新的類別：NSPersistentContainer，把上面整個stack都打包起來，現在只要初始化一個NSPersistentContainer，並且代入一些參數，接下來所有操作都可以圍繞在這個container上面就好，相當方便。

設定環境

知道了Core Data stack是怎樣的東西之後，我們就要來設定我們的Core Data環境。如果你是在啟動Project時，就勾選Use Core Data，那Xcode會自動幫你在AppDelegate裡面產生必要的code，但如果你是後來才加的，記得要在AppDelegate裡面設定好container：

lazy var persistentContainer: NSPersistentContainer = {
		let container = NSPersistentContainer(name: "PersistentTodoList")
		container.loadPersistentStores(completionHandler: { (storeDescription, error) in
			if let error = error as NSError? {
				fatalError("Unresolved error \(error), \(error.userInfo)")
			}
		})
		return container
	}()

一般來說一個App只會有一個persistent store，這也就是為甚麼我們需要一個全域的container，目的就是為了方便讓其它class取用相同的container，而不會造成混淆。

一個基本的Todo list，至少要能夠寫上要做的事項，並且要能標示是否完成，所以我們的Data Model需要描述一個具有以下attributes的entity：

  • name (string)
  • finished (bool)

所以設定上會長這樣：

設計TodoStorageManager

設定完Core Data stack之後，我們可以開始來設計我們主要拿來操作Core Data的類別：TodoStorageManager，這個manager的功用，就是負責所有跟Core Data的互動，簡化操作的細結，讓資料處理可以盡量獨立於其它邏輯之外。我們目前規劃的功能，就是簡單的CRUD。

因為這個manager主要操作的環境就是Core Data，所以我們的dependency自然而然就會是persistent container，初始化設定如下：

class ToDoStorgeManager {
	
	let persistentContainer: NSPersistentContainer!
	
	//MARK: Init with dependency
	init(container: NSPersistentContainer) {
		self.persistentContainer = container
self.persistentContainer.viewContext.automaticallyMergesChangesFromParent = true
	}
	
	convenience init() {
		//Use the default container for production environment
		guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else {
			fatalError("Can not get shared app delegate")
		}
		self.init(container: appDelegate.persistentContainer)
	}
}

上面設定了一個convenience init，放入預設的dependency，也就是全域的container，這樣一來在production環境要取用這個manager會比較簡單，也比較容易在看code時候就知道它的功用。

另外，我們希望在操作Core Data時，寫入在背景thread執行，這樣可以避免效能上的問題。在NSPersistentContainer裡，預設會提供兩種context：viewContext跟backgroundContext。viewContext就是運行在main thread上的context，而利用NSPersistentContainer.newBackgroundContext()產生的context，就是backgroundContext，會在背景thread執行資料庫操作。

在這邊我們預設我們的背景任務(所有寫入的任務)都只需要在同一個背景thread執行，所以我們會直接建立一個backgroundContext供使用：

lazy var backgroundContext: NSManagedObjectContext = {
		return self.persistentContainer.newBackgroundContext()
}()

最後，操作的部份實作如下：

//MARK: CRUD
func insertTodoItem( name: String, finished: Bool ) -> ToDoItem? {

	guard let toDoItem = NSEntityDescription.insertNewObject(forEntityName: "ToDoItem", into: backgroundContext) as? ToDoItem else { return nil }
	toDoItem.name = name
	toDoItem.finished = finished
	
	return toDoItem
}

func remove( objectID: NSManagedObjectID ) {
	let obj = backgroundContext.object(with: objectID)
	backgroundContext.delete(obj)
}

func fetchAll() -> [ToDoItem] {
	let request: NSFetchRequest<ToDoItem> = ToDoItem.fetchRequest()
	let results = try? persistentContainer.viewContext.fetch(request)
	return results ?? [ToDoItem]()
}

func save() {
	if backgroundContext.hasChanges {
		do {
			try backgroundContext.save()
		} catch {
			print("Save error \(error)")
		}
	}	
}

到這裡，最簡單的manager就寫完了，它現在可以新增、讀取跟刪除todo item了。

Unit Test Setup

接著我們要開始來撰寫測試的code，依照我們的規劃，我們需要以下幾個測試case：

  1. 要能成功新增Todo並回傳ToDoItem物件
  2. 要能取得目前資料庫中的todos
  3. 要能成功刪除資料庫中的todo
  4. 呼叫save()，要能夠對資料庫執行Save

確定了我們的目標之後，我們就可以開始來設置我們的測試了，首先我們先設定好我們的SUT：

var sut: ToDoStorgeManager! 
override func setUp() {
	super.setUp()
	sut = ToDoStorgeManager(container: mockPersistantContainer)
}

其中mockPersistentContainer就是一個mock container，我們想要拿它來取代真的container。對Core Data來說，persistent store應該要是sqlite或是binary store，這樣才能把資料永久儲存下來。問題是，這兩樣都是我們目前無法mock的東西，所以我們需要利用不一樣的測試技巧，來達到替換環境的目的。

Fake - In-memory data store

Core Data本身有提供一種特別的store type：NSInMemoryStoreType。這個NSInMemoryStoreType，對Core Data來說，也是一種persistent store，跟sqlite或是binary不一樣的地方是，這個store的資料，只會儲存在記憶體裡面。也就是說只要App一關掉，所有的資料就會消失。我們可以利用這樣的特性，來做一個假的、只存在記憶體裡面的store，讓unit test code可以自由取用，又不用擔心資料跟production的搞混。這種方法，通常在測試技巧裡面被稱做為：Fake，也就是透過製作一個非常接近真實環境的物件，來讓測試能夠盡可能與真實隔離，但又能像是在真實環境中執行一樣。

Objects actually have working implementations, but usually take some shortcut which makes them not suitable for production - Martin Fowler

所以我們就利用這個假資料庫，來製作我們的mock container吧！

lazy var mockPersistantContainer: NSPersistentContainer = {

	let container = NSPersistentContainer(name: "PersistentTodoList", managedObjectModel: self.managedObjectModel)
	let description = NSPersistentStoreDescription()
	description.type = NSInMemoryStoreType
	description.shouldAddStoreAsynchronously = false // Make it simpler in test env
	
	container.persistentStoreDescriptions = [description]
	container.loadPersistentStores { (description, error) in
		// Check if the data store is in memory
		precondition( description.type == NSInMemoryStoreType )

		// Check if creating container wrong
		if let error = error {
			fatalError("Create an in-mem coordinator failed \(error)")
		}
	}
	return container
}()

讓我們來仔細分析一下裡面的內容：

let container = NSPersistentContainer(name: "PersistentTodoList", managedObjectModel: self.managedObjectModel)

這行會初始化一個container，並且指定managedModel。因為在我們的test target裡面，namespace跟production target是不一樣的，如果我們不指定managedModel，NSPersistentContainer會無法抓到我們的的managedModel，也就是.xcdatamodeld檔案。所以這邊我們必須要手動讓test code先抓到那個.xcdatamodeld，然後餵進container裡面，如此一來才能夠共享同樣的database schema。這個managedObjectModel設定如下：

lazy var managedObjectModel: NSManagedObjectModel = {
	let managedObjectModel = NSManagedObjectModel.mergedModel(from: [Bundle(for: type(of: self))] )!
	return managedObjectModel
}()

直接透過bundle把managedObjectModel抓進test target使用，而不仰賴NSPersistentContainer的自動判斷機制。另外，因為預設.xcdatamodeld是不會compile進test target的，所以我們也需要把.xcdatamodeld這個檔案加到test target裡面：

接下來，就是這個Fake的關鍵：

let description = NSPersistentStoreDescription()
description.type = NSInMemoryStoreType

container的屬性，可以透過NSPersistentStoreDescription來指定，所以我們就把我們的store設定成是InMemoryType，現在，對這個container的操作，就像在夢境裡一樣，不管你怎樣做，都不會影響真實世界了！

Stub - Canned responses

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. - Martin Fowler

根據Martin Fowler的定義，stub就是一些已經寫死的罐頭回傳值，常見的使用情境是：我要測試我的parser正不正確，我就先準備好一份raw data，讓它通過parser，最後比對出來的結果跟我準備的資料有沒有對應。在我們的這個case，我們利用stub，來測試我們對資料庫的操作，是不是有真的在進行，也就是，我們準備一些stubs，把它們塞進剛剛的假資料庫中，因為我們已經預先知道資料庫中有那些資料了，接下來我們就可以測試執行新增是不是真的會多一筆資料，刪除是不是會少一筆資料等等。以下是我們產生Stub的方法：

func initStubs() {
	
	func insertTodoItem( name: String, finished: Bool ) -> ToDoItem? {
		
		let obj = NSEntityDescription.insertNewObject(forEntityName: "ToDoItem", into: mockPersistantContainer.viewContext)
		
		obj.setValue("1", forKey: "name")
		obj.setValue(false, forKey: "finished")

		return obj as? ToDoItem
	}
	
	_ = insertTodoItem(name: "1", finished: false)
	_ = insertTodoItem(name: "2", finished: false)
	_ = insertTodoItem(name: "3", finished: false)
	_ = insertTodoItem(name: "4", finished: false)
	_ = insertTodoItem(name: "5", finished: false)
	
	do {
		try mockPersistantContainer.viewContext.save()
	}  catch {
		print("create fakes error \(error)")
	}
	
}

在這邊，我們直接操作資料庫，放進五筆資料，當作我們的stubs。需要注意的是，因為namespace不同的關係，我們的insert跟edit都不能直接使用ToDoItem，也就是不能用Xcode自動產生的NSManagedObject subclass，而是要用最原始的操作Core Data的方式：用NSManagedObject.setValue(, forKey:)來存取資料，不然會發生找不到entity的問題。偉哉Xcode！另外，這邊使用viewContext來做寫入，是因為我希望讓這個寫入是同步的，要確保這些Stub在test case執行前，就已經產生好並且放入資料庫。

再來，對Unit Test來說，每跑一個test case，都要像是展開新的人生一樣，要是全新的空白的。小魯的人生是黑白的，而測試更慘，只能是空白的。千萬不能出現這個test case被上一個test case影響的狀況，這點非常重要，所以我們要有一個能夠把資料全部清掉的方法：

func flushData() {
	let fetchRequest:NSFetchRequest<NSFetchRequestResult> = NSFetchRequest<NSFetchRequestResult>(entityName: "ToDoItem")
	let objs = try! mockPersistantContainer.viewContext.fetch(fetchRequest)
	for case let obj as NSManagedObject in objs {
		mockPersistantContainer.viewContext.delete(obj)
	}
	try! mockPersistantContainer.viewContext.save()
}

這邊一樣，不能對ToDoItem這個自動生成的class做任何操作，所以我們使用最原始的方試操作Core Data，再跟我念一次，偉哉Xcode~

把這兩個方法加到setUp()跟tearDown()之後，我們就可以確保每個test case都是嶄新的開始了！

override func setUp() {
	super.setUp()
	initStubs() // Create stubs
	sut = ToDoStorgeManager(container: mockPersistantContainer)
}

override func tearDown() {
	flushData() // Clear all stubs
	super.tearDown()
}

Test Cases

經過了長時間的鋪陳，終於要進入我們的主菜了，主菜相對很簡單，只要跟隨 Given, When, Assert這樣的模式，就可以順利寫出每個test case，以下我們先把新增、讀取、跟移除的test case寫完：

func test_create_todo() {
	
	//Given the name & status
	let name = "Todo1"
	let finished = false
	
	//When add todo
	let todo = sut.insertTodoItem(name: name, finished: finished)
	
	//Assert: return todo item
	XCTAssertNotNil( todo )

}

func test_fetch_all_todo() {
	
	//Given a storage with two todo
	
	//When fetch
	let results = sut.fetchAll()
	
	//Assert return two todo items
	XCTAssertEqual(results.count, 5)
}

func test_remove_todo() {
	
	//Given a item in persistent store
	let items = sut.fetchAll()
	let item = items[0]
	
	let numberOfItems = items.count
	
	//When remove a item
	sut.remove(objectID: item.objectID)
	sut.save()
	
	//Assert number of item - 1
	XCTAssertEqual(numberOfItemsInPersistentStore(), numberOfItems-1)
	
}

//Convenient method for getting the number of data in store now
func numberOfItemsInPersistentStore() -> Int {
	let request: NSFetchRequest<NSFetchRequestResult> = NSFetchRequest(entityName: "ToDoItem")
	let results = try! mockPersistantContainer.viewContext.fetch(request)
	return results.count
}

在testfetchalltodo()中，因為我們已經知道stub總共的數量是5個，所以我們直接使用5來當做我們的assertion。

另外，在testremovetodo()裡面，我們做了一些妥協，因為我們的寫入是寫到backgroundContext，但我們的numberOfItemsInPersistentStore()卻是讀viewContext的資料，所以我們需要先執行save()這個side effect，才能assert正確的數量。未來可以透過mock一個完全客制化的NSPersistentContainer，產生指定的backgroundContext來解決這個問題，不過這邊讓我們先專注在fake跟stub就好。

上面這些東西的操作，全部都是在記憶體中操作，但對我們的SUT來說，因為接口一模一樣，都是NSPersistentContainer，所以互動的方式跟production是一模一樣的。

Expectations to Notification

到此，我們還有一個case還沒有寫到：

  1. 呼叫save()，要能夠對資料庫執行Save

這個case的目的，是要確保我們的ToDoStorageManager.save()真的有呼叫到NSManagedObjectContext.save()，讓資料真的有寫入persistent store。依照我們平常mock的作法，我們應該要建立一個NSManagedObjectContextProtocol，並且產生一個mock來conform這個protocol，然後利用mock來得知NSManagedObjectContext.save()是不是真的有被呼叫(再次宣傳一下，可以參考拙作(https://www.codementor.io/koromiko/unit-test-for-networking-ahdpdqr5k))。但問題來了，我們的dependency是NSPersistentContainer，所有的context都被封裝在這個container之中，並且目前也沒有方法可以在container中植入自己的context，所以我們必須要找別的方法來做這個behavior test。

如果不能透過mock來了解save()的運作，我們還有另外一個妥協的方法，在Core Data，只要context有變動，都會發出對應的notification，我們只要聽這些notification，就可以知道我們的SUT是不是真的有對context下save()。在這邊我們會專注在NSManagedObjectContextDidSave這個notification，這個notification會在資料被存回persistent store後觸發，只要有收到這個notification，就表示NSManagedContext.save()是有被觸發的。

所以我們在setUp()裡面，註冊這個notification：

NotificationCenter.default.addObserver(self, selector: #selector(contextSaved(notification:)), name: NSNotification.Name.NSManagedObjectContextDidSave , object: nil)

然後設定好這個notification的handler：

func contextSaved( notification: Notification ) {
}

接著我們來看一下我們save()的測試code：

func test_save() {
			
	//Give a todo item
	let name = "Todo1"
	let finished = false
	
	_ = expectationForSaveNotification()
	
	_ = sut.insertTodoItem(name: name, finished: finished)
	
	//When save
	sut.save()
	
	//Assert save is called via notification (wait)
	waitForExpectations(timeout: 1, handler: nil)

}

在這一個case之中，我們做的事情是：新增一個todo list，並且等待NSManagedObjectContextDidSave(也就是expectationForSaveNotification)，在一秒內收到這個notification(也就是waitForExpectations)，這個test case才算有過。因為notification是一個非同步的行為，所以我們需要利用XCTestExpectation，來做非同步的測試。讓我們先來看一下expectationForSaveNotification()的實作：

func expectationForSaveNotification() -> XCTestExpectation {
	let expect = expectation(description: "Context Saved")
	//After Do something async {
		expect.fulfill()
		// }
	return expect
}

expectation(description: "Context Saved”)是一個在XCTestCase已經定義的method，目地是要設定一個XCTestExpectation物件，並且將這個expectation加入清單，接著只要在你的test case裡面加上waitForExpectations(timeout: TimeInterval, handler: XCTest.XCWaitCompletionHandler? = nil)，那個test case就會一直等待，等到expect.fulfill()被觸發之後，才會通過測試，如果在timeout設定的時間前，都沒收到任何fulfill()的呼叫，這個case就會被判定失敗。

接著，因為我們等待的是一個notification，所以上面的After Do something async，會這樣實作：

//MARK: Convinient function for notification
var saveNotificationCompleteHandler: ((Notification)->())?

func waitForSavedNotification(completeHandler: @escaping ((Notification)->()) ) {
	saveNotificationCompleteHandler = completeHandler
}

func contextSaved( notification: Notification ) {
	saveNotificationCompleteHandler?(notification)
}

在waitForSavedNotification中，我們先把complete handler存下來，等到在contextSaved(Notification:)中收到notification之後，再呼叫這個handler，達到async的效果，一旦這個complete handler被呼叫了，就會觸發expect.fulfill()，而waitForExpectations就會被滿足，測試case也就順利通過了！

Recap

在這篇文章中，我們學習到了：

  1. 怎樣用NSPersistentContainer設定Core Data stack
  2. 怎樣設定Fake及Stub for Core Data
  3. 怎麼在XCTestCase中做非同步的測試

完整的程式可以在我的Github(https://github.com/koromiko/Tutorial/tree/master/PersistentTodoList)上面找到。

Summary

對Core Data來說，其實有許許多多種測試的方法，最常見的還是mock NSManagedObjectContext，也有許多文章已經有做過探討：

How to Create Mocks and Stubs in Swift - Andrew Bancroft(https://www.andrewcbancroft.com/2014/07/15/how-to-create-mocks-and-stubs-in-swift/)

Real-World Testing with XCTest · objc.io(https://www.objc.io/issues/15-testing/xctest/#core-data)

不過為了要符合iOS 10以後新的Core Data stack用法，小弟試著做了一些研究，試著在NSPersistentContainer的狀況下做測試，雖然很多地方需要稍微繞路一下，但整體來說該測試的地方都還是可以完整地測試，並且也相當獨立於真實環境之外，希望這些方法能夠帶來一點幫助。

最後，在寫這篇文章的同時，已經越來越多人投入Realm的懷抱了，找了一個大大詢問Core Data的細節，想不到他直接跟我說他只有用Realm從來沒用過Core Data，這就是時代的眼淚嗎QQ

References

Core Data Programming Guide: Persistent Store Types and Behaviors(https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/PersistentStoreFeatures.html)

iOS 10 Core Data In Memory Store for Unit Tests - Stack Overflow(https://stackoverflow.com/questions/39004864/ios-10-core-data-in-memory-store-for-unit-tests)

Data Models and Model Objects · objc.io(https://www.objc.io/issues/4-core-data/core-data-models-and-model-objects/#data-model)

Real-World Testing with XCTest · objc.io(https://www.objc.io/issues/15-testing/xctest/#why-we-are-testing)

Easier Core Data Setup with Persistent Containers(https://useyourloaf.com/blog/easier-core-data-setup-with-persistent-containers/)

TestDouble(https://martinfowler.com/bliki/TestDouble.html)

Share
Show Comments

Topics