原文出處: http://chengway.in/post/ji-zhu/core-data-by-tutorials-bi-ji-liu
今天我們來關(guān)注一下CoreData的單元測(cè)試,其實(shí)在寫程序之前,先寫測(cè)試,將問題一點(diǎn)點(diǎn)分解,也是TDD所倡導(dǎo)的做法,這也是我今年所期望達(dá)成的一個(gè)目標(biāo),新開項(xiàng)目按TDD的流程來做,以后也會(huì)整理些這方面的東西。如果你對(duì)CoreData的其他方面感興趣請(qǐng)查看我之前的筆記或直接購(gòu)買《Core Data by Tutorials》
作者列舉了一系列單元測(cè)試的好處:幫助你在一開始就組織好項(xiàng)目的結(jié)構(gòu),可以不用操心UI去測(cè)試核心功能。單元測(cè)試還可以方便重構(gòu)。還可以更好地拆分UI進(jìn)行測(cè)試。
這章主要焦距在XCTest這個(gè)框架來測(cè)試Core Data程序,多數(shù)情況下Core Data的測(cè)試要依賴于真實(shí)的Core Data stack,但又不想將單元測(cè)試的test data與你手動(dòng)添加的接口測(cè)試弄混,本章也提供了解決方案。
本章要測(cè)試的是一個(gè)關(guān)于野營(yíng)管理的APP,主要管理營(yíng)地、預(yù)訂(包括時(shí)間表和付款情況)。作者將整個(gè)業(yè)務(wù)流程分解為三塊:
由于swift內(nèi)部的訪問控制,app和其test分別屬于不同的targets和不同的modules,因此你并不能普通地從tests中訪問app中的classes,這里有兩個(gè)解決辦法:
作者提供的實(shí)例中,已經(jīng)將要測(cè)試的類和方法標(biāo)記為public的了,現(xiàn)在就可以對(duì)Core Data部分進(jìn)行測(cè)試了,作者在測(cè)試開始前給了一些建議:
Good unit tests follow the acronym?FIRST:
??Fast: If your tests take too long to run, you won’t bother running them.
??Isolated: Any test should function properly when run on its own or before or after any other test.
??Repeatable: You should get the same results every time you run the test against the same codebase.
??Self-verifying: The test itself should report success or failure; you shouldn’t have to check the contents of a file or a console log.
??Timely: There’s some benefit to writing the tests after you’ve already written the code, particularly if you’re writing a new test to cover a new bug. Ideally, though, the tests come first to act as a specification for the functionality you’re developing.
為了達(dá)到上面提到“FIRST”目標(biāo),我們需要修改Core Data stack使用in-memory store而不是SQLite-backed store。具體的做法是為test target創(chuàng)建一個(gè)CoreDataStack的子類來修改store type。
class TestCoreDataStack: CoreDataStack {
override init() {
super.init()
self.persistentStoreCoordinator = {
var psc: NSPersistentStoreCoordinator? = NSPersistentStoreCoordinator(managedObjectModel:
self.managedObjectModel)
var error: NSError? = nil
var ps = psc!.addPersistentStoreWithType(
NSInMemoryStoreType, configuration: nil,
URL: nil, options: nil, error: &error)
if (ps == nil) {
abort()
}
return psc
}()
}
}
單元測(cè)試需要將APP的邏輯拆分出來,我們創(chuàng)建一個(gè)類來封裝這些邏輯。作者這里創(chuàng)建的第一個(gè)測(cè)試類為CamperServiceTests是XCTestCase的子類,用來測(cè)試APPCamperService類中的邏輯
import UIKit
import XCTest
import CoreData
import CampgroundManager
//
class CamperServiceTests: XCTestCase {
var coreDataStack: CoreDataStack!
var camperService: CamperService!
override func setUp() {
super.setUp()
coreDataStack = TestCoreDataStack()
camperService = CamperService(managedObjectContext: coreDataStack.mainContext!, coreDataStack: coreDataStack)
}
override func tearDown() {
// Put teardown code here. This method is called after the invocation of each test method in the class.
super.tearDown()
coreDataStack = nil
camperService = nil
}
func testAddCamper() {
let camper = camperService.addCamper("Bacon Lover", phoneNumber: "910-543-9000")
XCTAssertNotNil(camper, "Camper should not nil")
XCTAssertTrue(camper?.fullName == "Bacon Lover")
XCTAssertTrue(camper?.phoneNumber == "910-543-9000")
}
setUp會(huì)在每次測(cè)試前被調(diào)用,這里可以創(chuàng)建一些測(cè)試需要用到東西,而且因?yàn)槭褂玫氖莍n-memory store,每次在setUp中創(chuàng)建的context都是全新的。tearDown相對(duì)于setUp,是在每次test結(jié)束后調(diào)用,用來清除一些屬性。上面的例子主要測(cè)試了addCamper()方法。
這里注意的就是該測(cè)試創(chuàng)建的對(duì)象和屬性都不會(huì)保存在任何store中的。
關(guān)于異步測(cè)試,這里用到了兩個(gè)context,一個(gè)root context運(yùn)行在后臺(tái)線程中,另外一個(gè)main context是root context的子類,讓context分別在正確的線程中執(zhí)行其實(shí)也很簡(jiǎn)單,主要采用下面兩種方法:
測(cè)試第二種performBlock()方法時(shí)可能會(huì)需要些技巧,因?yàn)閿?shù)據(jù)可能不會(huì)立即得到,還好XCTestCase提供了一個(gè)叫expectations的新特性。下面展示了使用expectation來完成對(duì)異步方法的測(cè)試:
let expectation = self.expectationWithDescription("Done!");
someService.callMethodWithCompletionHandler() {
expectation.fulfill()
}
self.waitForExpectationsWithTimeout(2.0, handler: nil)
該特性的關(guān)鍵是要么是expectation.fulfill()被執(zhí)行,要么觸發(fā)超時(shí)產(chǎn)生一個(gè)異常expectation,這樣test才能繼續(xù)。
我們現(xiàn)在來為CamperServiceTests繼續(xù)增加一個(gè)新的方法來測(cè)試root context的保存:
func testRootContextIsSavedAfterAddingCamper() {
//1 創(chuàng)建了一個(gè)針對(duì)異步測(cè)試的方法,主要是通過觀察save方法觸發(fā)的通知,觸發(fā)通知后具體的handle返回一個(gè)true。
let expectRoot = self.expectationForNotification(
NSManagedObjectContextDidSaveNotification,
object: coreDataStack.rootContext) {
notification in
return true
}
//2 增加一個(gè)camper
let camper = camperService.addCamper("Bacon Lover",
phoneNumber: "910-543-9000")
//3 等待2秒,如果第1步?jīng)]有return true,那么就觸發(fā)error
self.waitForExpectationsWithTimeout(2.0) {
error in
XCTAssertNil(error, "Save did not occur")
}
}
這一節(jié)新建了一個(gè)CampSiteServiceTests?Class 對(duì)CampSiteService進(jìn)行測(cè)試,具體code形式與上一節(jié)類似,添加了測(cè)試testAddCampSite()和testRootContextIsSavedAfterAddingCampsite(),作者在這里主要展示了TDD的概念。
Test-Driven Development (TDD) is a way of developing an application by writing a test first, then incrementally implementing the feature until the test passes. The code is then refactored for the next feature or improvement.
根據(jù)需求又寫了一個(gè)testGetCampSiteWithMatchingSiteNumber()方法用來測(cè)試getCampSite(),因?yàn)閏ampSiteService.addCampSite()方法在之前的測(cè)試方法中已經(jīng)通過測(cè)試了,所以這里可以放心去用,這就是TDD的一個(gè)精髓吧。
func testGetCampSiteWithMatchingSiteNumber(){
campSiteService.addCampSite(1, electricity: true,
water: true)
let campSite = campSiteService.getCampSite(1)
XCTAssertNotNil(campSite, "A campsite should be returned")
}
func testGetCampSiteNoMatchingSiteNumber(){
campSiteService.addCampSite(1, electricity: true,
water: true)
let campSite = campSiteService.getCampSite(2)
XCTAssertNil(campSite, "No campsite should be returned")
}
寫完測(cè)試方法運(yùn)行一下CMD+U,當(dāng)然通不過啦,我們還沒有實(shí)現(xiàn)他?,F(xiàn)在為CampSiteService類添加一個(gè)getCampSite()方法:
public func getCampSite(siteNumber: NSNumber) -> CampSite? {
let fetchRequest = NSFetchRequest(entityName: "CampSite") fetchRequest.predicate = NSPredicate(
format: "siteNumber == %@", argumentArray: [siteNumber])
var error: NSError?
let results = self.managedObjectContext.executeFetchRequest(
fetchRequest, error: &error)
if error != nil || results == nil {
return nil
}
return results!.first as CampSite?
}
現(xiàn)在重新CMD+U一下,就通過了。
最后一節(jié)主要針對(duì)APP中的ReservationService類進(jìn)行測(cè)試,同樣的是創(chuàng)建一個(gè)ReservationServiceTests測(cè)試類,這個(gè)test類的setUP和tearDown與第三節(jié)類似。只不過多了campSiteService與camperService的設(shè)置。在testReserveCampSitePositiveNumberOfDays()方法中對(duì)ReservationService類里的reserveCampSite()進(jìn)行測(cè)試后,發(fā)現(xiàn)沒有對(duì)numberOfNights有效性進(jìn)行判斷,隨后進(jìn)行了修改,這也算是展示了單元測(cè)試的另一種能力。作者是這么解釋的:不管你對(duì)這些要測(cè)試的code有何了解,你盡肯能地針對(duì)這些API寫一些測(cè)試,如果OK,那么皆大歡喜,如果出問題了,那意味著要么改進(jìn)code要么改進(jìn)測(cè)試代碼。
更多建議: