什么时候用到单元测试:
1、写完代码以后:想要验证一下自己写的代码是否有问题。
2、写代码之前:就是写代码之前所有的功能分模块的设计好,测试通过了再写。(我反正是没用过)。
3、修复某个bug后:一般修复完某个bug,为了确保修复是成功的,会写测试。
1、怎么写单元测试
创建一个工程,名字随便取,直接勾选include Unit Tests
万一我忘了勾选怎么办呢?可以有其他方式创建File–>new–>target–>iOS–>iOS Unit Testing Bundle。名字自己看着办吧。
工程创建好后,那要怎么开始测试呢?
找到系统单元测试Testes文件夹中.m文件看中会到看到几个方法,我们来看下这个几个方法是什么时候调用和他们各种的作用
- (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 {
// This is an example of a functional test case.
// Use XCTAssert and related functions to verify your tests produce the correct results.
// 测试用例的例子,注意测试用例一定要test开头
}
- (void)testPerformanceExample {
// This is an example of a performance test case.
// 测试性能例子
[self measureBlock:^{
// Put the code you want to measure the time of here.
// 需要测试性能的代码
}];
}
在ViewController中写一个简单的方法
- (int)getNum;
实现:
- (int)getNum {
return 100;
}
在测试的文件中导入ViewController.h,并且定义一个vc属性
#import <XCTest/XCTest.h>
#import "ViewController.h"
@interface ____Tests : XCTestCase
@property (nonatomic,strong) ViewController *vc;
@end
@implementation ____Tests
- (void)setUp {
[super setUp];
// 实例化需要测试的类
self.vc = [[ViewController alloc] init];
}
- (void)tearDown {
// 清空
self.vc = nil;
[super tearDown];
}
- (void)testMyFuc {
// 调用需要测试的方法,
int result = [self.vc getNum];
// 如果不相等则会提示@“测试不通过”
XCTAssertEqual(result, 100,@"测试不通过");
}
command+u快捷方式运行,或者produce–>test都行,
工程就跑起来了
我们可以在在控制台清晰的看到我们要测试的用例子通过了,测试通过的测试方法会有绿色的钩。
这时候我们改下断言,把100随便改成一个数,120.再comand+u运行下,看下什么情况
很明显是能不能通过的,因为我们要测试的方法返回值是100,
自带的测试框架还能测试某个方法的性能,
- (void)testPerformanceExample {
// This is an example of a performance test case.
[self measureBlock:^{
// Put the code you want to measure the time of here.
for (int i = 0; i<100; i++) {
NSLog(@"dd");
}
}];
}
我们在例子中添加一个for循环,测试其性能。command+u运行就能看到如图:
能够非常直观的看出其调用的时间,可以用其来对比性能的优劣。
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");
}
控制台部分输出:
est 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段中地址是固定的,所以二者地址相同。
掌握了各个断言的含义,用起来就没什么大问题了。
参考于大神:
http://blog.csdn.net/chaoyuan899/article/details/25779295
http://www.jianshu.com/p/009844a0b9ed