OCMock 源码分析

2,189 阅读9分钟

前言

单元测试作为日常工作中不可或缺的部分,虽然增加了需求开发的工作量,但能在一定程度上提高代码的稳定性。特别是迭代时通常能更快更准确的验证以往的算法或边界是否异常,避免手工测试时漏掉历史逻辑细节。

对于新增代码来说,保证可测试性能让单测能顺畅的编写,不过若我们需要为历史代码添加单测,事情就变得复杂。对于 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);
}

KVO 实现会把对象的 isa 指向一个继承于原始类的子类并重写对应 setter,然后重写-class返回原始类。这里classToSubclassForObject:会判断若object被 KVO 监听,则返回原始类。

尝试把这个判断去掉后,Mock 一个之前被 KVO 处理的对象,然后在 Stop Mocking 之前触发 KVO,发现必然 Crash,IMP 地址非法。思考一下,此时 Mock 会把 KVO 类再次子类化,然后这个ocmock_replaced_anySetter指向的实现居然不是 KVO 类重写的 Setter?

去翻阅了 OCMock GitHub 上的 issue 和 PR 记录,发现确实是有这个问题,issue 地址是: github.com/erikdoe/ocm… 作者的类似描述:

It's been a while, but I recall not doing this was messing with KVO notifications + the associated tests. KVO dynamically subclasses your class to provide automatic notifications, and something about then re-subclassing that class wasn't working.

可以初步得出结论,被 KVO 处理后的 isa 指向的动态子类,再次子类化进行一些方法交换会出奇怪的问题,所以这里选择去 Mock KVO 动态子类的父类。

回到-initWithObject:方法,这里的初始化会调用[super initWithClass:class],也就是前面 Mock Class 的初始化方法,所以若使用 Mock Instance 的话其 Class 的 isa 也会被改掉,若使用到这个 Class 的话得注意,可能会由于多线程导致莫名其妙的问题。

上层功能

对于 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 问题时能提高排查的速度感觉就达到目的了。