●为什么需要单元测试
●减少代码中的低级错误。
●有效的降低bug的出现率。
●增强可维护性。
●有助于设计：写单元测试首先给了你一个如何设计 API 的清晰视角。
●质量保证，根据我的自身经历，让一个开发者记得要测试所有的特性，在代码改变后回归测试所有的功能以及新增或移除的功能，几乎是一件不可能的事情。
被测试的对象，方法大概分为三种:
●有明确的返回值，采用返回值验证法，验证返回值是否符合预期。
●没有返回值，但方法内部修改了对象的属性或者状态，采用状态验证法，是否符合预期。
●依赖于外部的类，方法，会调用外部的方法，采用行为验证法。
单元测试可能遇到的问题
●测试上下文有太多依赖，设计的耦合性太高。
●运行的速度缓慢，你的单元测试中可能存在外部系统，列入数据库，网络请求，文件系统等。
●改变一个地方，多处测试受影响，可能是测试设计的问题，也可能是代码的粒度拆分不够。
●怎样测试私有方法——私有方法有太多的行为 。
测试哪些东西
你在测试哪个组件切面（component aspect）？
这个特性做什么用？你测试的具体行为需求是什么？
针对行为的测试，这是一种行为驱动开发技术(BDD)，可以参考 unit-testing-tdd-and-bdd。那什么是行为？
你设计的App中有一个对象，它有一个接口定义了其方法和依赖关系。这些方法和依赖，声明了你对象的约定。它们定义了如何与你应用的其他部分交互，以及它的功能是什么。它们定义了对象的行为。这同时也是你的目标，测试对象的行为。
比如点击按钮是否触发了某个行为。
怎样进行单元测试
单元测试本质上来说就是用断言来判断对象是否达到预期的行为。
单元测试的关注点单一，单元测试需要保证你每个测试用例是针对一个单元，而不是一个有很多复杂依赖注入的综合行为。
我们尽可能让类方法的职责单一，这样才能保证变化点都集中在被测试的单元中。
单元测试一般比较静态，它只是验证某一动作的正确性。
大部分单元测试将针对对象的状态，来断言一个特定的交互是否发生，或者一个特定值是否返回。将依赖提取出来，这可以允许你轻松mock。
注意，你不该将对象的所有依赖都暴露在头文件中，尤其是你开始测试的时候，这样看起来很诱人，但会破坏你类结构的封装，你的接口应该只表述设计需求。
●充分了解需要测试的类的行为特性。
●对代码重构，针对这些行为编写单元测试。
●使用伪造类避免对其它类的依赖：被测试的方法需要某个对象作为参数，但测试类中并不关心对象的具体实现。
●伪造环境避免其它环境的干扰：比如在网络请求异步的环境中，测试代码不好写，可以将该步骤分开，测试请求网络行为，再模拟数据返回，测试网络数据返回后的行为。也可以采用GHUnit等第三方框架。
单元测试坏的实践
●不应该测试构造函数--构造函数中应该是实现类的一些细节，而我们是针对对象的行为做测试，所以构造函数没有值得测的东西。
●不要测试私有方法--私有方法意味着私有，如果你觉得你有必要测试私有方法，那可能你的私有方法中做的事太多了，从而违背了单一职责原则。
●不要stub私有方法--因为你的私有方法是可以在类中不经通知自由修改的，当stub私有方法后，私有方法修改后可能与你的期望背到而驰，但你的测试还是会通过，这是见很可怕的事情。
●不要stub第三方库--比如你stub了[AFNetworking sendRequest]方法，不需要通过实际的网络调用是测试内容更单一，当你更换了这个网络库之后，这个测试用例就会失效，而你实际上stub的目的就是模拟网络请求成功。所以测试中应该封装一层，来代替那个库的全部功能。
Given / When / Then 模式
将测试用例分为三个部分
●Given 部分，通过创建对象，活着stub对象，将测试的系统设定到指定的状态，来设置测试的环境。
●When 部分包含了我们具体需要测试的代码。
●Then 部分是验证测试的结果，是否达到我们的期望，对象是否有改变，返回值是否合格等。
下面是家园宝测试作业是否正常继续下载的例子：
-(void)testResumeWithHomeWorkModel{ //Given if (!self.manager) { self.manager = [DownLoadHomeWorkManager manager]; } HomeModel* homeModel = [[HomeModel alloc]init]; homeModel.pid = @"497"; //When [self.manager resumeTaskWith:homeModel]; //Then XCTAssertEqual(homeModel.status, HomeworkStateDownloading); } |
Mock
在iOS测试中的mock框架可以采用OCMock，我们用mock来管理一个对象的所有依赖。当被测试的方法里耦合着其它对象时，但是你不想让这个对象的返回值对这个方法有影响，你可以通过mock 的方式返回一个默认值。
另外，我们的测试代码中不能过度的使用mock，mock除去了被测试对象以外的其它对象，这样其它对象修改了之后，这个被测试的对象就不能自动失败。
单元测试的要求
●测试用例应该是自解释且独立的：每个测试用例应该不依赖于其它方法的结果作为输入，没有网络请求，没有数据库操作，保证其原子性。
●测试方法需要解释测试的目的：如 -(void)testObject 就不是一种规范的写法，每个方法的目标应该是单一的，大多数每个方法里都有一个断言。
●断言语句需要解释测试者的用途：如XCTAssertNotNil,[xxx should]beNil],等等。
●判断某个测试是否成功是检测方法影响的数据有没有合理的变化：由于单元测试是使用断言来判断的，单元测试中不会对显示层进行约束，所以限定了单元测试的范围，即引起数据的变化。
●对所有暴露的属性和方法提供测试，私有方法则不必：测试私有方式可以通过子类化，设计分类，kvo等方式获取私有或者内部对象。
●变化需要新测试的支持：当对外的接口的实现发生变化时，需要编写新的测试。
●发现bug 并修复后，为了确保修复时成功的，需要进行单元测试。
●测试有其他依赖时需要避免其它依赖的副作用，可以采用依赖注入的方法， 依赖注入 ，具体可以使用mock 或者真实对象注入。
●对每一个功能类都要做单元测试。
●单元测试需要描述和记录代码需要实现的所有需求。
单元测试框架
XCTest
XCTest 是iOS自带的一个测试框架，相比于其他第三方集成度高，能满足大部分测试需求。但是并没有提供mock的功能。
OCMock
OCMock 是一个OC的模拟对象库，他提供了关于mock 和 stub 的功能，可以和XCTest一起使用。它看起来像这样。
- (void)testAddDownLoadHomeWorkModel{ if (!self.manager) { self.manager = [DownLoadHomeWorkManager manager]; } HomeModel* homeModel = [[HomeModel alloc]init]; //mock 出一个dataCenter id dataCenter = OCMClassMock([HomeworkDataCenter class]); self.manager.dataCenter = dataCenter; homeModel.pid = @"497"; //该方法被调用时返回1 OCMStub([dataCenter insertHomeModel:homeModel]).andReturn(1); [self.manager addDownLoadTask:homeModel]; XCTAssertEqual(homeModel.status, HomeworkStateDownloading); } |
Kiwi
Kiwi 是一个行为驱动开发(BDD)的框架，它旨在解决具体问题，帮助开发人员确定应该测什么内容。你不应该关注于测试，而是应该关注于行为。
该框架相比iOS自带的XCTest，它的语法更类似于自然语言，易读性强。
Kiwi 更多使用方法点击 这里
SPEC_BEGIN(First) describe(@"First", ^{ context(@"create a string", ^{ __block NSString * name = nil; beforeEach(^{ name = @"aa"; }); it(@"name should be aa", ^{ [[name shouldNot]beNil]; }); }); }); SPEC_END |
测试实例
Unitest.png
首先，我们来看一下iOS的UIViewController。对代码分析时，发现大量的的逻辑都被写在 .m 文件里，我们知道，UIViewController 在 .h 里面暴露的方法很少，可是 .m 大量的逻辑单元测试又不能不做，这就相当于要对代码中的private 方法进行测试。
进一步分析发现，如果在ViewController 中 添加一个ViewModel层，将UIViewController 里的业务逻辑放入中间层，该层可以负责网络的请求，数据的处理等。一方面会使ViewController 更加简洁和实现单一原则，另一方面保证了逻辑的可能性，该中间层会对ViewController 暴露一些接口。在MVC的设计模式中，ViewController 承受了太多的任务导致测试的难度增加，将ViewController 拆分（MVVM）就会更加有利于单元测试。
describe(@"Bind ViewModel", ^{ __block WrapJSMessageView* replyView = nil; __block WrapJSMessageViewModel* replyViewModel = nil; replyView = [[WrapJSMessageView alloc]init]; replyViewModel = [[WrapJSMessageViewModel alloc]init]; replyView.replyViewModel = replyViewModel; context(@"Test Text Binding ", ^{ it(@"Image Should NotNil", ^{ [[replyViewModel.image shouldNot]beNil]; }); //select Image; { UIImage* image = [UIImage new]; NSDictionary* dict = @{}; [dict stub:@selector(objectForKey:) andReturn:image withArguments:@"UIImagePickerControllerOriginalImage"]; [replyView imagePickerController:[UIImagePickerController new] didFinishPickingMediaWithInfo:dict]; it(@"select Image", ^{ [[replyViewModel.image should]equal:image]; }); } // clear text { it(@"After reset Image should Be reset", ^{ [[replyView should]receive:@selector(resetReplyView)]; replyViewModel.text = nil; }); } UIButton* sendBtn = nil; [UIView getViewByTitle:@"发送" rootView:replyView resultView:&sendBtn]; // test Click ReplyBtn { it(@"Get Send Btn", ^{ [[sendBtn shouldNot]beNil]; }); } // Send Btn should Be disable { it(@"Send Btn should Disable", ^{ [[theValue(sendBtn.enabled)should] beFalse]; }); } //Send Btn should Be disable { it(@"Send Btn should Enable", ^{ replyViewModel.text = @"222"; [[theValue(sendBtn.enabled)should] beFalse]; }); } // ReplyBtnClicked { [[replyViewModel.replyCommand should]receive:@selector(execute:)]; it(@"Send Should Invalid", ^{ [sendBtn sendActionsForControlEvents:UIControlEventTouchUpInside]; }); } }); }) |
DetailNewViewController
describe(@"DetailNewViewController", ^{ __block DetailNewViewController* detail = [[DetailNewViewController alloc]init]; context(@"initial with valid post_id", ^{ id viewModel = OCMClassMock([PostDetailViewModel class]); detail.viewModel = viewModel; detail.postid = @"100"; it(@"initWithPostid should be invoked", ^{ OCMVerify([viewModel initWithPostId:[OCMArg any]]); }); }); context(@"Inital", ^{ PostDetailViewModel* viewModel = [[PostDetailViewModel alloc]initWithPostId:@"1"]; // 测试获取帖子数据 { MJRefreshGifHeader* header = nil; //获取header [UIView getRefeshHeader:detail.view resultView:&header]; it(@"RefreshController should not be nil", ^{ [[header shouldNot]beNil]; }); RACCommand* fetchRawCommand = OCMClassMock([RACCommand class]); viewModel.fetchRawDataCommand = fetchRawCommand; [detail viewDidLoad]; it(@"should Request Post Data", ^{ OCMVerify([header beginRefreshing]); }); } //测试获取评论列表 { NSDictionary* returnData = @{ @"ret":@(1), @"retCode":@(1), }; detail.viewModel = viewModel; id fetchReplyCommand = OCMClassMock([RACCommand class]); viewModel.fetchReplyListCommand = fetchReplyCommand; [detail showWithDict:returnData]; it(@"Then Request ReplyList Data", ^{ OCMVerify([fetchReplyCommand execute:[OCMArg any]]); }); } }); context(@"Test Click Collect Btn", ^{ detail.isIntersting = NO; detail.contentData = [NSDictionary mock]; PostDetailViewModel* viewModel = [[PostDetailViewModel alloc]init]; id command = OCMClassMock([RACCommand class]); viewModel.collectCommand = command; detail.viewModel = viewModel; [detail soucangBtnDidClicked]; it(@"Send NetWork should Raised ", ^{ OCMVerify([command execute:[OCMArg any]]); }); }); context(@"Test Click Uncollect Btn", ^{ detail.isIntersting = YES; detail.contentData = [NSDictionary mock]; PostDetailViewModel* viewModel = [[PostDetailViewModel alloc]init]; id command = OCMClassMock([RACCommand class]); viewModel.unCollectCommand = command; detail.viewModel = viewModel; [detail soucangBtnDidClicked]; it(@"Uncollected should Raised ", ^{ OCMVerify([command execute:[OCMArg any]]); }); }); context(@"Test NavgationItem ", ^{ UIView* title = detail.titleSegment; it(@"should Not Nil", ^{ [[title shouldNot]beNil]; }); it(@"should Be UISegmentControl", ^{ [[title should]beKindOfClass:[UISegmentedControl class]]; }); UISegmentedControl* segTitle = (UISegmentedControl*)title; it(@"should have Three Segment ", ^{ [[theValue(segTitle.numberOfSegments) should]equal:@(3)]; }); }); }) |
DetailNewViewController+Spec.h
#import "DetailNewViewController.h" @interface DetailNewViewController (Spec) @property(nonatomic,assign)NSInteger isIntersting; @property(nonatomic , strong) NSDictionary* contentData; @property(nonatomic , strong) UISegmentedControl* titleSegment; -(void)showWithDict:(NSDictionary*)dict; @end |
// UIView 的分类
#import "UIView+Spec.h" #import "MJRefresh.h" @class MJRefreshGifHeader; @implementation UIView (Spec) +(void)getRefeshHeader:(UIView*)rootView resultView:(UIView**)result{ for(UIView * view in rootView.subviews){ if ([view isKindOfClass:[MJRefreshGifHeader class]]) { *result = view; }else { [self getRefeshHeader:view resultView:result]; } } } +(void)getViewByTitle:(NSString*)title rootView:(UIView*)rootView resultView:(UIView**)result{ for(UIView * view in rootView.subviews){ if ([view isKindOfClass:[UIButton class]]&&[[(UIButton*)view titleLabel].text isEqualToString:title]) { *result = view; }else { [self getViewByTitle:title rootView:view resultView:result]; } } } @end |
BDD实例
我遇到的问题
刚开始做单元测试的时候，根本无法下手，帖子模块的版本迭代频繁，业务逻辑复杂，代码行数达到2400行左右。再看代码结构相当混乱。帖子模块所有的数据，包括从网络的发起，数据的接收，界面的显示都混杂在一起，只有少量的view 单独抽了出去，即使是封装的view，数据的显示还是在帖子的控制器中做的。这真的是MVC(Massive-View-Controller)了。为了方便测试，先找几个行为特性测起来，我把网络数据的请求和接受，全部封装到帖子的ViewModel中，抽离出回复框，并给这个view配备了一个ViewModel（因为回复框中也有不少的逻辑），控制器只需要新建并添加就ok了。这样针对回复框的一些行为就可以提取出来测了。帖子页一些行为可以在ViewModel 中测试。
在测试的过程中，由于大量的原生数据的显示逻辑都在帖子页的ViewController中，而在测试这个控制器的一些行为时，无法提供帖子的原生数据，或者说因为原生数据格式复杂而难以高效的注入，导致测试的时程序崩溃。经过思考，觉得还是应该将所有的数据交给ViewModel 管理，ViewController或View 应该仅仅和ViewModel 进行数据上的绑定。这样在测试ViewContrllor时就不会对数据有过多的依赖。在测试ViewModel时也能更集中的测试数据的有效性。
总结
在做单元测试的时候，更多思考一个对象的行为，它的接口应该如何，并减少对实现的关注。这样你会有更加健壮的代码，以及同样杰出的套件。单元测试的代码简单，但是写好单元测试却不是一件简单的事，对程序员的代码质量要求较高，如何有效的组织行为就考验程序员的水平了。从现在开始，让单元测试来帮你描述代码的行为。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
