Xcode 单元测试

最新推荐文章于 2024-04-24 23:16:26 发布

qinlicang

最新推荐文章于 2024-04-24 23:16:26 发布

阅读量6.5k

点赞数 1

分类专栏： IOS

IOS 专栏收录该内容

29 篇文章 0 订阅

订阅专栏

XCTEST 场景 / XCTEST 展望 / 评估 Block() 虽然WWDC 2014 上iOS 8 和Swift的发布引起了开发者的极大关注，但Xcode 6 在测试功能方面的提升和改进或许将会产生长期的深远的影响。本周，我们将关注XCTest，

“ ”

阅读器

原文:XCTestCase/XCTestExpectation/measureBlock()

虽然WWDC 2014 上iOS 8 和Swift的发布引起了开发者的极大关注，但Xcode 6 在测试功能方面的提升和改进或许将产生长期的深远影响。

本周，我们将关注 XCTest，这是内嵌到Xcode的测试框架，同时Xcode 6也添加了新特性：XCTestExpectation 和性能测试同样让人兴奋。

大部分Xcode 项目模板现在支持拆箱测试。例如，当一个新的iOS app在Xcode 中通过快捷键建立，最终工程文件将会通过两个顶级组来配置（除“Products”组之外）："AppName" & "AppNameTests"。工程自动生成的scheme可以使用快捷键建立并运行可执行的目标，并用来建立并运行测试目标。

在测试目标中有一个叫做AppNameTests的单独的文件，其包括一个exampleXCTestCase 类，由样式模板setUp & tearDown 方法组成，还包括一个功能和性能测试的示例。

XCTestCase

Xcode单元测试包含在一个 XCTestCase 的子类中。依据约束，每一个 XCTestCase 子类封装一个特殊的有关联的集合，例如一个功能、用例或者一个程序流。

通过一个可管理的大量测试用例分拆逻辑测试，在代码库的增长和进化方面会产生很多不同。

setUp & tearDown

setUp 在 XCTestCase 中的每一个测试运行前被调用，tearDown 在测试运行结束时被调用：

     
     class Tests: XCTestCase { 
    override func setUp() { 
        super.setUp() 
        // Put setup code here. This method is called before the invocation of each test method in the class. 
    } 
 
    override func tearDown() { 
        // Put teardown code here. This method is called after the invocation of each test method in the class. 
        super.tearDown() 
    } 
}

这些方法对用来建立测试用例的所有测试中用到的常见对象是有用的：

     
     var calendar: NSCalendar? 
var locale: NSLocale? 
 
override func setUp() { 
    super.setUp() 
 
    self.calendar = NSCalendar(identifier: NSGregorianCalendar) 
    self.locale = NSLocale(localeIdentifier: "en_US") 
}

由于 XCTestCase 不被考虑在一个测试用例定义中直接初始化，在setUp中的被共享的初始化属性便作为可选择的变量被声明。

功能测试

每一个名字中以“test”开始的方法被标识用来测试，并且将会评估函数中的所有断言来决定是否通过或者失败。例如，如果 1 + 1等于 2，函数 testOnePlusOneEqualsTwo 将会继续执行：

     
     func testOnePlusOneEqualsTwo() { 
    XCTAssertEqual(1 + 1, 2, "one plus one should equal two") 
}

所有你真正需要知道的 XCTest 断言

XCTest 带有许多内建的断言，但是可以精简成几个要点：

基础性测试

为了整体精简，所有的 XCTest 断言缩小为一个独立的、基础的断言：

     
     XCTAssert(expression, format...)

如果以上表达式判断为真，测试将会通过。否则，测试失败，将会打印格式化的消息。

虽然一个开发者能够只使用 XCTAssert，但是如下助手断言仍然提供了一些有用的语法帮助澄清正在进行的测试究竟是什么。如果可能，使用最明确的可用的断言，仅仅在可以更好表达意图的情况下使用 XCTAssert 。

布尔测试

布尔值或者简单的布尔表达式使用 XCTAssertTrue & XCTAssertFalse:

XCTAssert 等于 XCTAssertTrue

相等性测试

当要测试两个值是否相等时使用 XCTAssert[Not]Equal：

     
     XCTAssertEqual(expression1, expression2, format...) 
XCTAssertNotEqual(expression1, expression2, format...)

XCTAssert[Not]EqualObjects 在Swift 中不是必要的，因此在标量值和对象间没有区别。

当指定测试两个双精度，单精度，或者其他浮点值是否相等，使用 XCTAssert[Not]EqualWithAccuracy 来报告浮点精度问题。

     
     XCTAssertEqualWithAccuracy(expression1, expression2, accuracy, format...) 
XCTAssertNotEqualWithAccuracy(expression1, expression2, accuracy, format...)

除了前面提到的相等断言，还有XCTAssertGreaterThan[OrEqual] & XCTAssertLessThan[OrEqual] 提供了== ，>, >=, <, & <= 比较运算符。

空值测试

使用 XCTAssert[Not]Nil 断言一个给定的值是否存在（或者不存在）：

     
     XCTAssertNil(expression, format...) 
XCTAssertNotNil(expression, format...)

无条件失败

最终，XCTFail 断言将会总是失败：

     
     XCTFail(format...)

XCTFail 通常用来为一个将会被通过的测试指代一个占位符。

它对完成一个被其他流程控制结构发现的错误用例也是有用的，例如一个用来测试成功的 if 语句的 else 分句。

性能测试

Xcode 6的新特性能够检测代码性能：

     
     func testDateFormatterPerformance() { 
    let dateFormatter = NSDateFormatter() 
    dateFormatter.dateStyle = .LongStyle 
    dateFormatter.timeStyle = .ShortStyle 
 
    let date = NSDate() 
 
    self.measureBlock() { 
        let string = dateFormatter.stringFromDate(date) 
    } 
}

     
     Test Case '-[_Tests testDateFormatterPerformance]' started. 
<unknown>:0: Test Case '-[_Tests testDateFormatterPerformance]' measured [Time, seconds] average: 0.000, relative standard deviation: 242.006%, values: [0.000441, 0.000014, 0.000011, 0.000010, 0.000010, 0.000010, 0.000010, 0.000010, 0.000010, 0.000010], performanceMetricID:com.apple.XCTPerformanceMetric_WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100 
Test Case '-[_Tests testDateFormatterPerformance]' passed (0.274 seconds).

性能测试帮助为主要代码路径确定一个性能基准。将它们分散在你的测试用例中用来确认重要的算法以及随着时间的推移程序保持高性能。

XCTestExpectation

或许 Xcode 6 中新增的最让人兴奋的特性是内建的对于异步测试的支持，借助 XCTestExpectation 类来实现。现在，测试能够为了确定的合适的条件等待一个指定时间长度，而不需要求助于GCD。

要做一个异步测试，首先使用 expectationWithDescription 建立一个期望值。

     
     let expectation = expectationWithDescription("...")

然后，在方法底部，增加 waitForExpectationsWithTimeout 方法，指定一个超时，如果测试条件不适合时间范围便会结束执行：

     
     waitForExpectationsWithTimeout(10, handler: { error in 
    // ... 
})

现在，剩下的步骤是在异步方法被测试的相关的回调中实现那个期望值。

     
     expectation.fulfill()

如果测试有不止一个期望值，它将不会通过，除非每一次期望值在被 inwaitForExpectationsWithTimeout() 指定的超时中执行 fulfill()。

     
     expectation.fulfill()

这里有一个例子是如何能够使用XCTestExpectation API测试的异步网络请求：

     
     func testAsynchronousURLConnection() { 
    let URL = "http://nshipster.com/" 
    let expectation = expectationWithDescription("GET \(URL)") 
 
    let session = NSURLSession.sharedSession() 
    let task = session.dataTaskWithURL(NSURL(string: URL), completionHandler: {(data, response, error) in 
        expectation.fulfill() 
 
        XCTAssertNotNil(data, "data should not be nil") 
        XCTAssertNil(error, "error should be nil") 
 
        if let HTTPResponse = response as NSHTTPURLResponse! { 
            XCTAssertEqual(HTTPResponse.URL.absoluteString, URL, "HTTP response URL should be equal to original URL") 
            XCTAssertEqual(HTTPResponse.statusCode, 200, "HTTP response status code should be 200") 
            XCTAssertEqual(HTTPResponse.MIMEType as String, "text/html", "HTTP response content type should be text/html") 
        } else { 
            XCTFail("Response was not NSHTTPURLResponse") 
        } 
    }) 
 
    task.resume() 
 
    waitForExpectationsWithTimeout(task.originalRequest.timeoutInterval, handler: { error in 
        task.cancel() 
    }) 
}

用swift模拟

借助对异步测试一流的支持，Xcode 6 似乎已经完成一个现代的测试驱动的开发者的全部需求。好的，或许只剩下一个：mocking。

Mocking 对于隔离和控制行为是一个有用的技术，对于复杂的原因，非确定性的，或者性能约束，通常不会让其自身测试。例子包括模拟网络请求，精确数据查询，或者包括特殊的竞争条件。

有几个开源库用来建立仿真对象和剔除方法调用，但是这些库大量依赖 Objective-C 运行时操作，一些现在不可能使用Swift。

然而，实际上这或许在 Swift 中不是必需的，原因在于 Swift 极少的语法约束。

在Swift中，类可以在一个函数定义中声明，允许仿真对象完全自包含。只要声明一个仿真内联类，覆盖的和必需的方法如下：

     
     func testFetchRequestWithMockedManagedObjectContext() { 
    class MockNSManagedObjectContext: NSManagedObjectContext { 
        override func executeFetchRequest(request: NSFetchRequest!, error: AutoreleasingUnsafePointer<NSError?>) -> [AnyObject]! { 
            return [["name": "Johnny Appleseed", "email": "johnny@apple.com"]] 
        } 
    } 
 
    let mockContext = MockNSManagedObjectContext() 
    let fetchRequest = NSFetchRequest(entityName: "User") 
    fetchRequest.predicate = NSPredicate(format: "email ENDSWITH[cd] %@", "@apple.com") 
    fetchRequest.resultType = .DictionaryResultType 
 
    var error: NSError? 
    let results = mockContext.executeFetchRequest(fetchRequest, error: &error) 
 
    XCTAssertNil(error, "error should be nil") 
    XCTAssertEqual(results.count, 1, "fetch request should only return 1 result") 
 
    let result = results[0] as [String: String] 
    XCTAssertEqual(result["name"] as String, "Johnny Appleseed", "name should be Johnny Appleseed") 
    XCTAssertEqual(result["email"] as String, "johnny@apple.com", "email should be johnny@apple.com") 
}

使用 Xcode 6 我们已经最终实现目标：内建测试工具现在是足够好用了。也就是说，没有特殊的强制性的使用任何附加的抽象事物的理由，该抽象事物是用来为大量的app和库提供可接受的测试范围。除非在需要极端情况下，诸如：需要大量消除，仿真，或者其他独特的测试结构，XCTest 断言，期望值，和性能衡量将会是充分的。

但是不论多好的测试工具被创造出来，他们也只是取决于你如何能够实际使用他们。

如果你是iOS或者OS X测试方面的新人，给那些自动的和敲击?U生成的测试用例文件增加一些断言。你可能惊讶于多么容易-我敢说-你将会发现整个经历令人愉快。

在Objc.io #1的Testing View Controllers中讲解的就是单元测试的相关内容。本文说下如何通过Xcode 5中集成的XCTest框架进行简单的单元测试。

什么是单元测试

首先什么是单元测试？维基百科中的解释是：

在计算机编程中，单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书（en:Specification）要求的工作目标，没有程序错误；虽然单元测试不是什么必须的，但也不坏，这牵涉到项目管理的政策决定。

由于我们OC程序员写的通常都是面向对象的程序，所以我们在进行单元测试时，通常都是以一个方法为单位测试，目的当然是保证其不会出错了。按照Objc.io文章的观点，如果我们代码之间的耦合度很小，那么可以将其分解成多个小部件，从而更易于测试。

原文还提到一个概念：TDD(Test-Driven Development)，即测试驱动开发，该模式要求开发者在编写某个功能的代码之前先将其测试代码写好，然后编写实现代码并进行测试，从而保证实现的代码不会出现问题。因此整个项目的开发进度将由测试来驱动，这有助于开发出高质量而又正确的代码，实现敏捷开发。（Objc.io上面的文章真的非常的好）

好吧，科普完了，下面进入Xcode Unit Testing的部分。

XCTest

1.第一个单元测试

XCTest是Xcode 5中自带的测试框架，它和Xcode 4及之前的SenTestKit，OCUnit有什么前因后果，小弟没有做多少研究，所以不说了。

下面从一个Demo开始。首先用Xcode新建一个工程UnitTestDemo，工程目录结构如下：

可以看到工程下面多了一个叫UnitTestDemoTests的部分，Targets也多了一个UnitTestDemoTests，根据图标初步认为该Target跑的是一个框架。

这两个多出来的东西（相比Xcode 4没有Include Unit Tests的工程）就是用来做单元测试的，其特点是文件名或Target名都以Tests结尾。

再来看下UnitTestDemoTests.m中的代码：

 
       01. 
       #import <XCTest/XCTest.h> 
      
       02. 
         
       03. 
       @interface UnitTestDemoTests : XCTestCase 
      
       04. 
         
       05. 
       @end 
      
       06. 
         
       07. 
       @implementation UnitTestDemoTests 
      
       08. 
         
       09. 
       - (void)setUp 
      
       10. 
       { 
      
       11. 
       [super setUp]; 
      
       12. 
       // Put setup code here. This method is called before the invocation of each test method in the class. 
      
       13. 
       } 
      
       14. 
         
       15. 
       - (void)tearDown 
      
       16. 
       { 
      
       17. 
       // Put teardown code here. This method is called after the invocation of each test method in the class. 
      
       18. 
       [super tearDown]; 
      
       19. 
       } 
      
       20. 
         
       21. 
       - (void)testExample 
      
       22. 
       { 
      
       23. 
       XCTFail(@"No implementation for "%s"", __PRETTY_FUNCTION__); 
      
       24. 
       } 
      
       25. 
         
       26. 
       @end

该类继承自XCTestCase类，其中包含三个方法：setUp，tearDown和testExample。

setUp方法用于在测试前设置好要测试的方法，tearDown则是在测试后将设置好的要测试的方法拆卸掉。

testExample顾名思义就是一个示例。

按快捷键Command + U进行单元测试，结果如下：

可以看到没有通过测试，在Issue Navigator和控制台都输出了错误信息：本类中的testExample方法没有实现。

实际上，这个错误是我们主动抛出来的。XCTFail是一个宏，其作用就是让测试失败，后面的No implementation for "%s"", __PRETTY_FUNCTION__就是要报告的错误信息，由我们自定。

报错总是让人不爽，好吧，我们将其注释掉，另外写一个测试方法，尝点甜头。为了规范，建议每个测试方法都写成“ - (void)testXXX ”形式，XXX表示要测试的方法名，并且无返回类型。

 
       1. 
       //- (void)testExample 
      
       2. 
       //{ 
      
       3. 
       //    XCTFail(@"No implementation for "%s"", __PRETTY_FUNCTION__); 
      
       4. 
       //} 
      
       5. 
         
       6. 
       - (void)testTrue { 
      
       7. 
       XCTAssert(1, @"Can not be zero"); 
      
       8. 
       }

Command + U，搞定：

注意左边的Test Navigator，绿色的标志表示测试全部通过。

2.测试的顺序

如果在同一测试类文件中多写几个方法，例如：

 
       01. 
       - (void)testTrue2 { 
      
       02. 
       NSLog(@"2222222222222222222222"); 
      
       03. 
       XCTAssert(1, @"Can not be zero"); 
      
       04. 
       } 
      
       05. 
         
       06. 
       - (void)testTrue1 { 
      
       07. 
       NSLog(@"1111111111111111111111"); 
      
       08. 
       XCTAssert(1, @"Can not be zero"); 
      
       09. 
       } 
      
       10. 
         
       11. 
       - (void)testTrue3 { 
      
       12. 
       NSLog(@"3333333333333333333333"); 
      
       13. 
       XCTAssert(1, @"Can not be zero"); 
      
       14. 
       } 
      
       15. 
         
       16. 
       - (void)testAtrue { 
      
       17. 
       NSLog(@"0000000000000000000000"); 
      
       18. 
       XCTAssert(1, @"Can not be zero"); 
      
       19. 
       }

控制台部分输出：

 
       01. 
       Test Case '-[UnitTestDemoTests testAtrue]' started. 
      
       02. 
       2014-03-19 21:19:38.182 UnitTestDemo[7401:60b] 0000000000000000000000 
      
       03. 
       Test Case '-[UnitTestDemoTests testAtrue]' passed (0.001 seconds). 
      
       04. 
       Test Case '-[UnitTestDemoTests testTrue1]' started. 
      
       05. 
       2014-03-19 21:19:38.183 UnitTestDemo[7401:60b] 1111111111111111111111 
      
       06. 
       Test Case '-[UnitTestDemoTests testTrue1]' passed (0.000 seconds). 
      
       07. 
       Test Case '-[UnitTestDemoTests testTrue2]' started. 
      
       08. 
       2014-03-19 21:19:38.184 UnitTestDemo[7401:60b] 2222222222222222222222 
      
       09. 
       Test Case '-[UnitTestDemoTests testTrue2]' passed (0.013 seconds). 
      
       10. 
       Test Case '-[UnitTestDemoTests testTrue3]' started. 
      
       11. 
       2014-03-19 21:19:38.196 UnitTestDemo[7401:60b] 3333333333333333333333 
      
       12. 
       Test Case '-[UnitTestDemoTests testTrue3]' passed (0.001 seconds).

可以看到无论我们怎样调换test方法的书写顺序，其测试顺序都是不变的。

目前初步的结论：测试方法执行的顺序与方法名中test后面的字符大小有关，小者优先，例如testA，testB1，testB2三个方法相继执行。

3.断言测试

下面一共18个断言（SDK中也是18个，其含义转自ios UnitTest 学习笔记，真心佩服原文的博主，部分宏小弟已经测试过）：

XCTFail(format…) 生成一个失败的测试；

XCTAssertNil(a1, format...)为空判断，a1为空时通过，反之不通过；

XCTAssertNotNil(a1, format…)不为空判断，a1不为空时通过，反之不通过；

XCTAssert(expression, format...)当expression求值为TRUE时通过；

XCTAssertTrue(expression, format...)当expression求值为TRUE时通过；

XCTAssertFalse(expression, format...)当expression求值为False时通过；

XCTAssertEqualObjects(a1, a2, format...)判断相等，[a1 isEqual:a2]值为TRUE时通过，其中一个不为空时，不通过；

XCTAssertNotEqualObjects(a1, a2, format...)判断不等，[a1 isEqual:a2]值为False时通过；

XCTAssertEqual(a1, a2, format...)判断相等（当a1和a2是 C语言标量、结构体或联合体时使用,实际测试发现NSString也可以）；

XCTAssertNotEqual(a1, a2, format...)判断不等（当a1和a2是 C语言标量、结构体或联合体时使用）；

XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...)判断相等，（double或float类型）提供一个误差范围，当在误差范围（+/-accuracy）以内相等时通过测试；

XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...) 判断不等，（double或float类型）提供一个误差范围，当在误差范围以内不等时通过测试；

XCTAssertThrows(expression, format...)异常测试，当expression发生异常时通过；反之不通过；（很变态） XCTAssertThrowsSpecific(expression, specificException, format...) 异常测试，当expression发生specificException异常时通过；反之发生其他异常或不发生异常均不通过；

XCTAssertThrowsSpecificNamed(expression, specificException, exception_name, format...)异常测试，当expression发生具体异常、具体异常名称的异常时通过测试，反之不通过；

XCTAssertNoThrow(expression, format…)异常测试，当expression没有发生异常时通过测试；

XCTAssertNoThrowSpecific(expression, specificException, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过；

XCTAssertNoThrowSpecificNamed(expression, specificException, exception_name, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过

特别注意下XCTAssertEqualObjects和XCTAssertEqual。

XCTAssertEqualObjects(a1, a2, format...)的判断条件是[a1 isEqual:a2]是否返回一个YES。

XCTAssertEqual(a1, a2, format...)的判断条件是a1 == a2是否返回一个YES。

对于后者，如果a1和a2都是基本数据类型变量，那么只有a1 == a2才会返回YES。例如下面代码中只有第二行可以通过测试：

 
       1. 
       // 1.比较基本数据类型变量 
      
       2. 
       XCTAssertEqual(1, 2, @"a1 = a2 shoud be true"); // 无法通过测试 
      
       3. 
       XCTAssertEqual(1, 1, @"a1 = a2 shoud be true"); // 通过测试

但是，如果a1和a2都是指针，那么只有a1和a2指向同一个对象才会返回YES。例如下面的代码中：

 
       1. 
       // 3.比较NSArray对象 
      
       2. 
       NSArray *array1 = @[@1]; 
      
       3. 
       NSArray *array2 = @[@1]; 
      
       4. 
       NSArray *array3 = array1; 
      
       5. 
       XCTAssertEqual(array1, array2, @"a1 and a2 should point to the same object"); // 无法通过测试 
      
       6. 
       XCTAssertEqual(array1, array3, @"a1 and a2 should point to the same object"); // 通过测试

array1和array2指向不同对象，无法通过测试。

这里比较奇怪的是，NSString另当别论：

 
       1. 
       // 2.比较NSString对象 
      
       2. 
       NSString *str1 = @"1"; 
      
       3. 
       NSString *str2 = @"1"; 
      
       4. 
       NSString *str3 = str1; 
      
       5. 
       XCTAssertEqual(str1, str2, @"a1 and a2 should point to the same object"); // 通过测试 
      
       6. 
       XCTAssertEqual(str1, str3, @"a1 and a2 should point to the same object"); // 通过测试

尽管str1和str2指向不同的对象，但是二者的指针比较却能通过测试。不知道这是不是XCTest框架本身的一个Bug，反正在这里使用NSString要小心就是了。

掌握了各个断言的含义，用起来就没什么大问题了。

4.简单的应用

说了一大堆理论和定义，下面来点实际的应用。下面有一个表格控制器：

 
       01. 
       #import "TableViewController.h" 
      
       02. 
       #import "TableDataSource.h" 
      
       03. 
         
       04. 
       static NSString * const kCellIdentifier = @"Cell"; 
      
       05. 
         
       06. 
       @interface TableViewController () 
      
       07. 
         
       08. 
       @property (strong, nonatomic) TableDataSource *dataSource; 
      
       09. 
         
       10. 
       @end 
      
       11. 
         
       12. 
       @implementation TableViewController 
      
       13. 
       @synthesize dataSource = _dataSource; 
      
       14. 
         
       15. 
       - (void)viewDidLoad 
      
       16. 
       { 
      
       17. 
       [super viewDidLoad]; 
      
       18. 
         
       19. 
       TableViewCellConfigureBlock cellConfigureBlock = ^(UITableViewCell *cell, NSString *item) { 
      
       20. 
       cell.textLabel.text = item; 
      
       21. 
       }; 
      
       22. 
         
       23. 
       NSArray *stringsArray = @[@"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3"]; 
      
       24. 
       self.dataSource = [[TableDataSource alloc] initWithItems:stringsArray 
      
       25. 
       CellIdentifier:kCellIdentifier 
      
       26. 
       ConfigureCellBlock:cellConfigureBlock]; 
      
       27. 
         
       28. 
       self.tableView.dataSource = _dataSource; 
      
       29. 
       } 
      
       30. 
         
       31. 
       @end

该类的UITableViewDataSource委托由一个TableDataSource类实现（将UITableViewDataSource分离，见Objc.io #1Lighter View Controllers）。TableDataSource类的初始化方法如下：

 
       01. 
       - (instancetype)initWithItems:(NSArray *)anItems 
      
       02. 
       CellIdentifier:(NSString *)aCellIdentifier 
      
       03. 
       ConfigureCellBlock:(TableViewCellConfigureBlock)aConfigureCellBlock 
      
       04. 
       { 
      
       05. 
       self = [super init]; 
      
       06. 
         
       07. 
       if (self) { 
      
       08. 
       self.items              = anItems; 
      
       09. 
       self.cellIdentifier     = aCellIdentifier; 
      
       10. 
       self.configureCellBlock = [aConfigureCellBlock copy]; 
      
       11. 
       } 
      
       12. 
         
       13. 
       return self; 
      
       14. 
       }

下面写一个Tests类测试一下DataSource的初始化方法。首先新建一个test case class类：

继承自XCTestCase类：

为了规范，我们新建的测试类都应该以Tests结尾，例如CellConfigureTests。

然后写个testDataSourceInitializing方法：

 
       01. 
       - (void)testDataSourceInitializing { 
      
       02. 
       TableViewCellConfigureBlock cellConfigureBlock = ^(UITableViewCell *cell, NSString *item) { 
      
       03. 
       cell.textLabel.text = item; 
      
       04. 
       }; 
      
       05. 
         
       06. 
       TableDataSource *tableSource = [[TableDataSource alloc] initWithItems:@[@"1", @"2", @"3"] 
      
       07. 
       CellIdentifier:@"TestCell" 
      
       08. 
       ConfigureCellBlock:cellConfigureBlock]; 
      
       09. 
         
       10. 
       XCTAssertNotNil(tableSource, @"TableView data source should not be nil"); 
      
       11. 
       }

Command + U运行测试。如果TableDataSource初始化成功，那么tableSource将不会为nil，测试就能通过。

Demo下载地址：点此进入下载页

本文先说到这里，下一篇博客说下如何借助更加强大的OCMock和GHUnit进行单元测试。

qinlicang

关注

1
点赞
踩
4

收藏

觉得还不错? 一键收藏
1
评论
Xcode 单元测试

XCTEST 场景 / XCTEST 展望 / 评估 Block() 虽然WWDC 2014 上iOS 8 和Swift的发布引起了开发者的极大关注，但Xcode 6 在测试功能方面的提升和改进或许将会产生长期的深远的影响。本周，我们将关注XCTest，“”阅读器原文:XCTestCase/XCTestExpectati
复制链接

扫一扫