经典源码分析之 OCMock
Posted 知识小集
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了经典源码分析之 OCMock相关的知识,希望对你有一定的参考价值。
作者 | 波儿菜
前言
单元测试作为日常工作中不可或缺的部分,虽然增加了需求开发的工作量,但能在一定程度上提高代码的稳定性。特别是迭代时通常能更快更准确的验证以往的算法或边界是否异常,避免手工测试时漏掉历史逻辑细节。
对于新增代码来说,保证可测试性能让单测能顺畅的编写,不过若我们需要为历史代码添加单测,事情就变得复杂。对于 Objective-C 来说可能就得借助 OCMock 这种组件来伪造隐藏在代码细节中的测试条件。
然而大量使用 OCMock 给单测稳定性带来挑战,究其原因还是对 OCMock 本身的实现不够了解,可能它的一个实现细节就带来了多个不同的 Bad Case。所以笔者花了一些时间粗略的看了一下源码,简单做一些分析。
核心处理
Mock Class
OCMock 功能很多,不过基本上都是依赖于拦截方法做到的,既然要做到这一点就必然需要一个切面,下面看一个常用的宏:
OCMClassMock(TestObj.self);
Preprocess 后实际上会调用到:
[OCClassMockObject alloc] initWithClass:TestObj.self];
OCClassMockObject
类初始时就会做一个核心操作,将传入的 Class 的 isa 指向新的 meta,并将新的 meta 的方法列表进行一些置换操作,如下图所示:
这个实现类似于 KVO 的实现,不过后面还做了一个逻辑,对于新的 meta,为每一个 SEL 创建一个带ocmock_replaced_
前缀的 SEL,并且让这个带前缀的 SEL 指向原始实现,而原始 SEL 指向 NULL。值得注意的是,这里会遍历原始 meta 的整个继承链条的所有方法,在新 meta 里做同样的 SEL 的创建和置换操作。
消息转发
经过前面的处理,调用TestObj
的类方法时,objc_msgSend
找不到 IMP 就会指向_objc_msgForward
,从而触发消息重定向与转发。不过细心的同学可能会疑惑,这里触发的消息转发时机与上下文如何让 OCMock 组件感知到?实际上源码还做了一个处理:
Method myForwardMethod = class_getInstanceMethod([self mockObjectClass], @selector(forwardInvocationForClassObject:));
IMP myForwardIMP = method_getImplementation(myForwardMethod);
class_addMethod(newMetaClass, @selector(forwardInvocation:), myForwardIMP, method_getTypeEncoding(myForwardMethod));
就是把TestObj.self
新的 meta 的forwardInvocation:
方法指向OCClassMockObject
的一个方法实现,即forwardInvocationForClassObject:
,如此,TestObj
调用类方法触发消息转发时都会走到这个新方法,组件就成功拿到一个切面。
关于 +initialize
源码有一个细节,会为TestObj.self
新的 meta 添加一个initialize
方法的空实现,为了避免调用新 meta 的initialize
时走到 super meta 的initialize
导致 super meta 的这个方法调用多次,因为这个方法的调用是这样的:
((void(*)(Class, SEL))objc_msgSend)(cls, SEL_initialize);
实际上我们在编码中,都会在initialize
里面先做个if (self == AnyClass.self)
的判断,作者算是加了一层保险。
不支持的类和类方法
由于 OCMock 本身就是基于系统相关类、消息重定向与转发相关方法做的,所以肯定是得避免使用者去 Mock 这些类和方法,所以我们得大致清楚限制,避免编写单测时出现始料未及的情况。不支持的情况如下:
NSString/NSArray/NSManagedObject
类或其子类。@[@"class", @"forwardingTargetForSelector:", @"methodSignatureForSelector:", @"forwardInvocation:", @"isBlock", @"instanceMethodForwarderForSelector:", @"instanceMethodSignatureForSelector:"]
该数组包含的类方法。meta 类名包含
NS/UI
前缀,且类方法前缀或后缀包含_
(苹果的私有方法喜欢这么干)。
Mock Instance
对于实例的 Mock 使用的是这个宏:
OCMPartialMock(obj);
Preprocess 后实际上会调用到:
// OCPartialMockObject 继承自 OCClassMockObject
[[OCPartialMockObject alloc] initWithObject:anObject]
OCPartialMockObject
如法炮制,初始化时会把obj
对象的 isa 指向新的 Class,然后对 Class 的方法列表做一些置换操作,如下图所示:
对于新的 Class,为每一个 SEL 创建一个带ocmock_replaced_
前缀的 SEL,并且让这个带前缀的 SEL 指向原始实现,而原始 SEL 指向 NULL。这里会遍历 Class 继承链的所有方法,在新 Class 里做 同样的 SEL 的创建和置换操作。
消息转发
和前面的处理类似,只是这里添加了obj
所属新的 Class 的forwardInvocation:
和forwardingTargetForSelector:
两个方法实现。同时还实现了-class
方法返回obj
原始指向的 Class,和 KVO 一样达到瞒天过海的目的。
不支持的实例方法
对于实例变量的 Mock 同样有些方法是无效的:
@[@"class", @"forwardingTargetForSelector:", @"methodSignatureForSelector:", @"forwardInvocation:", @"allowsWeakReference", @"retainWeakReference", @"isBlock", @"retainCount", @"retain", @"release", @"autorelease"]
数组所有实例方法。类名包含
NS/UI
前缀,且实例方法前缀或后缀包含_
。
调用父类 OCClassMockObject 的初始化方法
OCPartialMockObject(父类是 OCClassMockObject)
初始化有这样的逻辑:
- (id)initWithObject:(NSObject *)anObject {
...
Class const class = [self classToSubclassForObject:anObject];
[super initWithClass:class];
...
}
- (Class)classToSubclassForObject:(id)object {
if([object observationInfo] != NULL)
return [object class];
return object_getClass(object);
}
下面的-classToSubclassForObject:
方法是个有趣的细节。
我们知道被 KVO 的对象的类会被重写-class
方法,返回实际类的一个父类。若这里直接通过object_getClass(...)
拿到实际类进行 Mock 操作,也就是把所有原来的方法的实现移除,若OCMStub
了某个被 KVO 重写过的 Setter 方法,那这个方法本来的实现就无法调用,造成 KVO 事件的丢失。
所以这里通过-observationInfo
判断,若对象有被 KVO 则取这个对象实际类的父类,把父类的 isa 改掉,然后 KVO 触发时仍然会,保证 KVO 正常运转。
回到主题,这里的初始化会调用[super initWithClass:class]
,也就是前面 Mock Class 的初始化方法,所以若使用 Mock Instance 的话其 Class 的 isa 也会被改掉,这点得注意。
上层功能
对于 Class 和 Instance 的 Mock 操作就是 OCMock 的核心逻辑,其它的大量功能代码都是依托于这些基础工作之上。既然已经拿到了类/实例方法调用的一个统一切面,做任何功能都只需要简单的代码处理就行了。
由于代码很多且作者的实现有些绕,下面就简单分析一下OCMStub
操作。
id mockObj = OCMClassMock(TestObj.self);
OCMStub([mockObj logString]);
[TestObj logString];
Preprocess 后的代码:
id mockObj = [OCClassMockObject alloc] initWithClass:TestObj.self];
({ ({
[OCMMacroState beginStubMacro];
OCMStubRecorder *recorder = ((void *)0);
@try{
[mockObj logString];
} @finally {
recorder = [OCMMacroState endStubMacro];
}
recorder;
}); });
[TestObj logString];
[OCMMacroState beginStubMacro]
会先创建一个上下文OCMMacroState
对象放入 TLS:
+ (void)beginStubMacro {
OCMStubRecorder *recorder = [[[OCMStubRecorder alloc] init] autorelease];
OCMMacroState *macroState = [[OCMMacroState alloc] initWithRecorder:recorder];
[NSThread currentThread].threadDictionary[OCMGlobalStateKey] = macroState;
[macroState release];
}
而[mockObj logString]
肯定会找不到方法,消息转发到OCClassMockObject
的父类OCMockObject
重定向方法:
- (id)forwardingTargetForSelector:(SEL)aSelector {
if([OCMMacroState globalState] != nil) {
OCMRecorder *recorder = [[NSThread currentThread].threadDictionary[OCMGlobalStateKey] recorder];
[recorder setMockObject:self];
return recorder;
}
return nil;
}
可以看到这里重定向到了之前的recorder
,然后又走recorder
的消息转发,最后会生成一个NSInvocation
对象存储到OCClassMockObject
对象里面。
当调用[TestObj logString]
时会找不到方法,然后转发到前面提到的-forwardInvocationForClassObject:
方法,里面会与刚存入的NSInvocation
对象比较,若匹配到了,这个调用就不会生效,也就是达到了我们拦截方法的目的,若没有匹配到,就调用ocmock_replaced_
前缀的 SEL 触发原本的方法实现。
这部分逻辑其实感觉挺绕,基于 TLS 的设计也注定做不到线程安全。至于OCMStub
验证参数,或OCMExpect/OCMVerify
都是类似的处理,本质上就两个操作:记录、验证。
不安全的 Stop Mocking
在OCPartialMockObject
和OCClassMockObject
调用-dealloc
时会执行-stopMocking
操作,也就是把之前的 Mock 逻辑都清理掉恢复现场。
OCMock 本身未支持多线程,-stopMocking
也是不安全的,有这样一个 Crash 的场景:当调用 Mock 对象(或被 Mock 对象)的-foo
方法后,之后经过一系列消息转发处理-foo
才最终调用,由于对象是被 Mock 过的,所以调用原方法实现是调用ocmock_replaced_
为前缀的方法,只要这期间进行了-stopMocking
操作,就可能导致 isa 指向复原而找不到ocmock_replaced_
为前缀的方法。
在单测实践中遇到过类似的问题,下面是总结的几点来规避错误:
尽量不显式使用
-stopMocking
,Mock 对象释放时会触发。当被测试的业务代码在异步线程使用了被 Mock 的对象/类,使用
XCTestExpectation
挂起单测线程直到异步逻辑处理完毕,或者使用OCMStub(...)
将异步线程调用的那个方法拦截掉。使用
OCMVerify(...)
和OCMStub(...)
一系列的宏需要注意,宏展开后会走一次括号内的代码。比如OCMVerify([obj foo]);
时,若-foo
里面有异步逻辑,参考第 2 点。OCMPartialMock(obj)
时不单是obj
指向的Class
改变,Class
指向的metaClass
也会改变,所以当使用这个宏后,obj
指向Class
的类方法调用仍然需要考虑异步问题,参考第 2 点。
注意 Class 和 Instance 的 Mock 对象不能混用
id mock = OCMPartialMock(obj);
// fooMethode 是类方法
OCMStub(mock fooMethode]);
这里 Mock 的是 Instance,不应该去 Stub 类方法。由于OCMStub
的设计就没有去区分调用时 Target 是 Class 还是 Instance,所以若有相同方法名的-fooMethode
实例方法,开发者可能误以为 Mock 的是类方法,实际上组件认为 Mock 的是实例方法。
后语
总的来说 OCMock 的核心部分设计得比较精致,里面大量的 Type Encoding 处理需要时也可以借鉴一下。但上层功能的实现感觉有些烧脑,可能主要是由于整个工程代码都是基于继承来实现的,有些地方感觉徒增复杂性,看源码的时候各种多态、各种父类链调用、各种变量漫天飞,确实比较头疼,但笔者也没太多精力去思考更优的处理,所以也不太敢说代码设计有问题。
写了一段时间的单测,源码基本上是用一些琐碎的时间看的,本文主要是把核心逻辑理了一下,没有过多的去纠结细节,只要下次单测再出 OCMock 问题时能提高排查的速度感觉就达到目的了。
几个月没写东西了,已累趴:joy:。
推荐阅读
☞
☞
☞
就差您点一下了
以上是关于经典源码分析之 OCMock的主要内容,如果未能解决你的问题,请参考以下文章
转:《Linux设备驱动程序3》源码目录结构和源码分析经典链接
Android 插件化VirtualApp 源码分析 ( 目前的 API 现状 | 安装应用源码分析 | 安装按钮执行的操作 | 返回到 HomeActivity 执行的操作 )(代码片段
Android 逆向整体加固脱壳 ( DEX 优化流程分析 | DexPrepare.cpp 中 dvmOptimizeDexFile() 方法分析 | /bin/dexopt 源码分析 )(代码片段
Android 事件分发事件分发源码分析 ( Activity 中各层级的事件传递 | Activity -> PhoneWindow -> DecorView -> ViewGroup )(代码片段