经典源码分析之 OCMock_vlambda技术博客

vlambda
2020-08-07

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

vlambda博客
学习文章列表