`
sunwu2010
  • 浏览: 2156 次
  • 性别: Icon_minigender_1
  • 来自: 武汉
文章分类
社区版块
存档分类
最新评论

ios 单元测试

    博客分类:
  • IOS
阅读更多

什么是单元测试

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

在计算机编程中,单元测试(又称为模块测试, 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中的代码:

#import <XCTest/XCTest.h>  
  
@interface UnitTestDemoTests : XCTestCase  
  
@end  
  
@implementation UnitTestDemoTests  
  
- (void)setUp  
{  
    [super setUp];  
    // Put setup code here. This method is called before the invocation of each test method in the class.  
}  
  
- (void)tearDown  
{  
    // Put teardown code here. This method is called after the invocation of each test method in the class.  
    [super tearDown];  
}  
  
- (void)testExample  
{  
    XCTFail(@"No implementation for \"%s\"", __PRETTY_FUNCTION__);  
}  
  
@end  

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

setUp方法用于在测试前设置好要测试的方法,tearDown则是在测试后将设置好的要测试的方法拆卸掉。testExample顾名思义就是一个示例。

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

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

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

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

//- (void)testExample  
//{  
//    XCTFail(@"No implementation for \"%s\"", __PRETTY_FUNCTION__);  
//}  
  
- (void)testTrue {  
    XCTAssert(1, @"Can not be zero");  
}  

Command + U,搞定:

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

2.测试的顺序

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

- (void)testTrue2 {  
    NSLog(@"2222222222222222222222");  
    XCTAssert(1, @"Can not be zero");  
}  
  
- (void)testTrue1 {  
    NSLog(@"1111111111111111111111");  
    XCTAssert(1, @"Can not be zero");  
}  
  
- (void)testTrue3 {  
    NSLog(@"3333333333333333333333");  
    XCTAssert(1, @"Can not be zero");  
}  
  
- (void)testAtrue {  
    NSLog(@"0000000000000000000000");  
    XCTAssert(1, @"Can not be zero");  
}

控制台部分输出:

Test Case '-[UnitTestDemoTests testAtrue]' started.  
2014-03-19 21:19:38.182 UnitTestDemo[7401:60b] 0000000000000000000000  
Test Case '-[UnitTestDemoTests testAtrue]' passed (0.001 seconds).  
Test Case '-[UnitTestDemoTests testTrue1]' started.  
2014-03-19 21:19:38.183 UnitTestDemo[7401:60b] 1111111111111111111111  
Test Case '-[UnitTestDemoTests testTrue1]' passed (0.000 seconds).  
Test Case '-[UnitTestDemoTests testTrue2]' started.  
2014-03-19 21:19:38.184 UnitTestDemo[7401:60b] 2222222222222222222222  
Test Case '-[UnitTestDemoTests testTrue2]' passed (0.013 seconds).  
Test Case '-[UnitTestDemoTests testTrue3]' started.  
2014-03-19 21:19:38.196 UnitTestDemo[7401:60b] 3333333333333333333333  
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.比较基本数据类型变量  
XCTAssertEqual(1, 2, @"a1 = a2 shoud be true"); // 无法通过测试  
XCTAssertEqual(1, 1, @"a1 = a2 shoud be true"); // 通过测试  

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

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

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

这里比较奇怪的是,NSString另当别论:

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

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

由于str1和str2指向同一常量,常量在内存的data段中地址是固定的,所以二者地址相同。

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

4.简单的应用

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

#import "TableViewController.h"  
#import "TableDataSource.h"  
  
static NSString * const kCellIdentifier = @"Cell";  
  
@interface TableViewController ()  
  
@property (strong, nonatomic) TableDataSource *dataSource;  
  
@end  
  
@implementation TableViewController  
@synthesize dataSource = _dataSource;  
  
- (void)viewDidLoad  
{  
    [super viewDidLoad];  
      
    TableViewCellConfigureBlock cellConfigureBlock = ^(UITableViewCell *cell, NSString *item) {  
        cell.textLabel.text = item;  
    };  
      
    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"];  
    self.dataSource = [[TableDataSource alloc] initWithItems:stringsArray  
                                              CellIdentifier:kCellIdentifier  
                                          ConfigureCellBlock:cellConfigureBlock];  
      
    self.tableView.dataSource = _dataSource;  
}  
  
@end 

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

- (instancetype)initWithItems:(NSArray *)anItems  
               CellIdentifier:(NSString *)aCellIdentifier  
           ConfigureCellBlock:(TableViewCellConfigureBlock)aConfigureCellBlock  
{  
    self = [super init];  
      
    if (self) {  
        self.items              = anItems;  
        self.cellIdentifier     = aCellIdentifier;  
        self.configureCellBlock = [aConfigureCellBlock copy];  
    }  
      
    return self;  
}  

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

继承自XCTestCase类:

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

然后写个testDataSourceInitializing方法:

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

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

 

 

 

 

分享到:
评论

相关推荐

    iOS单元测试最佳实践

    在进行iOS单元测试时,为了能够有效地进行代码测试和保证软件质量,开发者们通常会遵循一系列的最佳实践。这些最佳实践不仅能够帮助开发者们更加高效地编写测试用例,还能够确保测试用例能够覆盖应用的关键部分,...

    iOS单元测试大礼包

    这个“iOS单元测试大礼包”为你提供了全面的学习资源,包括8个演示实例(demo)和3个视频教程,帮助你深入理解和掌握iOS单元测试的技术和实践。 首先,我们要理解什么是单元测试。单元测试是对软件中的最小可测试...

    iOS单元测试实例

    "iOS单元测试实例"提供了关于如何在iOS应用中实现和利用单元测试的实践案例。在这个实例中,我们将探讨`iOS_Calc`和`Calculator-iOS`两个项目,它们可能是模拟一个简单计算器的应用,用于演示单元测试的基本概念和...

    iOS单元测试

    "iOS单元测试"主要关注的是对应用程序中的各个独立组件,如函数、方法或类进行测试,以验证它们按照预期工作。单元测试可以帮助开发者在早期发现并修复问题,避免在集成阶段出现难以追踪的错误。 GHUnit是专门为iOS...

    BaiduHiDeviOS#iOS-Tech-Weekly#iOS单元测试1

    1、最小可测单元 2、不是为了发现bug,是为了提高开发效率,为了我们的代码健康可持续发展 1、好的单元测试就是一份上好的文档,而且比文档更容易被程序员接受 2

    (李智维)单元测试与自动化.pdf

    ### 单元测试与自动化——李智维 iOS 开发经验分享 #### 一、作者背景介绍 李智维,一位年轻的技术人才,21岁时已积累了丰富的开发经验。他在中学时期就参加了算法竞赛,展现了其对编程技术的兴趣与天赋。大学期间...

    iOS单元测试框架KiwiforiOS.zip

    Kiwi 是 Objective-C 的单元测试框架,因其简单的接口而著名,基于 Objective-C 编写,只支持 iOS 应用 示例代码: describe(@"Team", ^{ context(@"when newly created", ^{ it(@"should have a name", ^{ ...

    iOS单元测试之XCTest详解

    **iOS单元测试之XCTest详解** 测试是软件开发过程中至关重要的一环,特别是对于App开发,良好的测试能够确保代码的稳定性和可靠性。XCTest是Apple为iOS开发者提供的一个强大的测试框架,它涵盖了单元测试、集成测试...

    swift-Spry是基于Nimble的SwiftPlaygrounds单元测试库

    `swift-Spry` 是一个专门为SwiftPlaygrounds设计的单元测试库,它基于另一个知名的测试匹配框架`Nimble`。下面我们将深入探讨`swift-Spry`及其相关知识点。 首先,我们需要了解`Nimble`。`Nimble`是由Quick项目提供...

Global site tag (gtag.js) - Google Analytics