经典源码分析之 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

OCPartialMockObjectOCClassMockObject调用-dealloc时会执行-stopMocking操作,也就是把之前的 Mock 逻辑都清理掉恢复现场。

OCMock 本身未支持多线程,-stopMocking也是不安全的,有这样一个 Crash 的场景:当调用 Mock 对象(或被 Mock 对象)的-foo方法后,之后经过一系列消息转发处理-foo才最终调用,由于对象是被 Mock 过的,所以调用原方法实现是调用ocmock_replaced_为前缀的方法,只要这期间进行了-stopMocking操作,就可能导致 isa 指向复原而找不到ocmock_replaced_为前缀的方法。

在单测实践中遇到过类似的问题,下面是总结的几点来规避错误:

  1. 尽量不显式使用-stopMocking,Mock 对象释放时会触发。

  2. 当被测试的业务代码在异步线程使用了被 Mock 的对象/类,使用XCTestExpectation挂起单测线程直到异步逻辑处理完毕,或者使用OCMStub(...)将异步线程调用的那个方法拦截掉。

  3. 使用OCMVerify(...)OCMStub(...)一系列的宏需要注意,宏展开后会走一次括号内的代码。比如OCMVerify([obj foo]);时,若-foo里面有异步逻辑,参考第 2 点。

  4. 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的主要内容,如果未能解决你的问题,请参考以下文章

如何进行 Java 代码阅读分析?

转:《Linux设备驱动程序3》源码目录结构和源码分析经典链接

Android 插件化VirtualApp 源码分析 ( 目前的 API 现状 | 安装应用源码分析 | 安装按钮执行的操作 | 返回到 HomeActivity 执行的操作 )(代码片段

Android 逆向整体加固脱壳 ( DEX 优化流程分析 | DexPrepare.cpp 中 dvmOptimizeDexFile() 方法分析 | /bin/dexopt 源码分析 )(代码片段

Android 事件分发事件分发源码分析 ( Activity 中各层级的事件传递 | Activity -> PhoneWindow -> DecorView -> ViewGroup )(代码片段

机器学习经典算法源码分析系列-- 线性回归