iOS中如何对具有复杂依赖的SDK在真机上进行单元测试

单元测试在软件开发中一直有着极其重要的地位，iOS的开发也不例外。随着App规模的不断膨胀，开发也逐渐的趋向模块化，开发者常常以库的形式封装功能，最后组成App。此时由于App结构变得复杂，各种库又可能存在着相互依赖的缘故，单元测试也随之变得复杂起来。开发者可能面临着一系列问题，比如：单元测试如何处理这些依赖？如何在真机上运行测试？如何在App所在的环境中运行测试？本文将用一个模拟的开发环境逐一进行讨论。

目录


在刚刚接触软件开发时，从未想过要写单元测试，总觉得自己写的代码质量很高，根本不需要测试。需要将宝贵的时间放到开发上，测试是测试人员的事情。后面才发现，经常因为一个小需求的增加，动了一处代码，结果其它地方出现重大问题，没测试到就上线了。甚至到了后面，代码复杂度越来越高，每动一处代码都提心吊胆，生怕有其它情形未考虑到，如履薄冰。经历了很多次惨痛教训之后才醒悟过来，单元测试是保证代码质量的不二法则。在《代码重构》一书中，每进行一步重构，作者都会先运行一遍单元测试，然后再进行后面的重构，因为只有这样，才能够保证重构之后代码的正确性，如果连正确都无法保证，重构有何意义？

Apple从Xcode 5开始，引入了最新的测试框架XCTest，非常完美的将测试与开发环境集成在了一起。关于如何使用XCTest，网上有非常多的介绍，大家可以看看Apple的官方文档，NSHipster也写过一篇文章：Unit Testing。

随着开发者越来越重视单元测试，有人提出了TDD(测试驱动开发)，并得到了很多开发者的推崇。这种思想会先根据需求或者接口来编写测试用例，然后才开始写业务代码，这样极大的保证了写出来的代码的正确性。关于在iOS上使用TDD，OneV写过一篇TDD的iOS开发初步以及Kiwi使用入门，有兴趣的可以去看看，这里不再展开介绍，本文集中讨论下面特定场景中的单元测试。

问题

iOS开发现在多数都使用CocoaPods进行第三方库的依赖管理，这样开发者们可以集中注意力放在自己模块的开发上面。比如著名的网络库AFNetworking。它的开源代码中也包含了单元测试，写得非常好，可以作为范例去学习。

但是由于AFNetworking本身的特点，决定了其单元测试环境其实是比较简单的，比如：

  • AFNetworking算是一个独立的库，并没有依赖其它的第三方库
  • 不依赖复杂的App环境
  • 不依赖真机环境

然而，很多时候，我们的开发环境比AFNetworking复杂得多，比如：

  • 依赖其它的第三方库，如何处理这些依赖的问题？
  • 依赖的某些第三方库又必须运行在复杂的App环境中，如何让测试运行于App环境？
  • 某些方法必须在真机上才能运行，如何让测试运行于真机上？

这些问题AFNetworking的测试用例都没有，而且默认创建的测试target都无法运行在这些环境中。如何利用XCTest来对以上复杂情形下的SDK进行单元测试？我们从模拟以上开发环境开始。

搭建SDK开发环境

首先我们来搭建一个满足以上复杂条件但却典型的开发环境：创建三个工程，其中ECApp是最终应用，它依赖了我们正在开发的ECSDK，而后者又依赖了第三方库EC3rdFramework。整个目录结构为：

.
├── EC3rdFramework
│   ├── EC3rdFramework.podspec
│   ├── EC3rdFramework.xcodeproj
│   ├── Podfile
│   ├── Sources
│   │   ├── ECFoo.h
│   │   └── ECFoo.m
│   └── SupportingFiles
├── ECApp
│   ├── ECApp
│   │   ├── AppDelegate.h
│   │   ├── AppDelegate.m
│   │   ├── Assets.xcassets
│   │   │   └── AppIcon.appiconset
│   │   │       └── Contents.json
│   │   ├── Base.lproj
│   │   │   ├── LaunchScreen.storyboard
│   │   │   └── Main.storyboard
│   │   ├── Info.plist
│   │   ├── ViewController.h
│   │   ├── ViewController.m
│   │   └── main.m
│   ├── ECApp.xcodeproj
│   └── Podfile
└── ECSDK
    ├── ECSDK.podspec
    ├── ECSDK.xcodeproj
    ├── Podfile
    ├── Sources
    │   ├── ECUsingFoo.h
    │   └── ECUsingFoo.m
    └── SupportingFiles

第三方库：EC3rdFramework

EC3rdFramework是我们开发的ECSDK所依赖的第三方库，其中包含一个ECFoo类，含有三个方法，分别模拟三种场景：

// ECFoo.m
// 模拟不依赖任何环境
- (BOOL)methodDependsOnNothing {
    return YES;
}

// 模拟依赖应用的环境
- (BOOL)methodDependsOnAppEnv {
    NSNumber *appInitialized = [[NSUserDefaults standardUserDefaults] objectForKey:@"AppInitialized"];
    if (appInitialized) {
        NSLog(@"running in app env");
        return YES;
    } else {
        NSLog(@"NOT running in app env");
        return NO;
    }
}

// 模拟依赖真实设备
- (BOOL)methodMustBeRunningOnDevice {
#if TARGET_IPHONE_SIMULATOR
    NSLog(@"running on simulator");
    return NO;
#else
    NSLog(@"running on device");
    return YES;
#endif
}

三个方法非常简单的模拟了三种典型的场景，满足条件时才会返回YES，代码很简单。对于依赖应用环境的场景，是通过App设置的一个标志位来判断，后面ECApp部分会看到这个标志位的设置。

其podspec如下：

Pod::Spec.new do |s|
  s.name                = "EC3rdFramework"
  s.version             = "1.0.0"
  s.requires_arc        = true
  s.source_files        = [ '**/Sources/**/*.h', '**/Sources/**/*.m']
  s.ios.deployment_target = '7.0'
end

开发中的SDK：ECSDK

ECSDK为我们所开发的SDK，它同EC3rdFramework一样，也是一个静态库，包含ECUsingFoo类，与前面的ECFoo类包含相同的方法，每个方法直接调用ECFoo中对应的方法，这样做是为了模拟依赖第三方库的场景：

// ECUsingFoo.m
#import <EC3rdFramework/ECFoo.h>
// ...
- (BOOL)methodDependsOnNothing {
    ECFoo *foo = [ECFoo new];
    return [foo methodDependsOnNothing];
}

- (BOOL)methodDependsOnAppEnv {
    ECFoo *foo = [ECFoo new];
    return [foo methodDependsOnAppEnv];
}

- (BOOL)methodMustBeRunningOnDevice {
    ECFoo *foo = [ECFoo new];
    return [foo methodMustBeRunningOnDevice];
}

同前面类似，它的podspec如下，区别在于它多了对第三方库的依赖：

Pod::Spec.new do |s|
  s.name                = "ECSDK"
  s.version             = "1.0.0"
  s.requires_arc        = true
  s.source_files        = [ '**/Sources/**/*.h', '**/Sources/**/*.m']
  s.dependency          'EC3rdFramework'
  s.ios.deployment_target = '7.0'
end

也是因为这个依赖，还需要一个Podfile：

target "ECSDK" do
  pod 'EC3rdFramework', :path => '../EC3rdFramework'
end

最终应用：ECApp

ECApp为使用ECSDK的App，它启动之后立刻调用ECSDK中暴露的接口：

// AppDelegate.m
#import <ECSDK/ECUsingFoo.h>
// ...
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Override point for customization after application launch.

    [[NSUserDefaults standardUserDefaults] setObject:[NSNumber numberWithBool:YES] forKey:@"AppInitialized"];
    [[NSUserDefaults standardUserDefaults] synchronize];

    ECUsingFoo *foo = [ECUsingFoo new];
    [foo methodDependsOnNothing];
    [foo methodDependsOnAppEnv];
    [foo methodMustBeRunningOnDevice];
    return YES;
}

方法的前两行，先设置了App环境的标识，前面ECFoo中便是依赖于此标识来判断是否处于App的环境中。

它的Podfile也很简单：

target "ECApp" do
  pod 'EC3rdFramework', :path => '../EC3rdFramework'
  pod 'ECSDK', :path => '../ECSDK'
end

这里有一点需要注意的是，实际上ECApp不会直接去依赖EC3rdFramework，它是被ECSDK依赖，按理说不需要加到Podfile中，CocoaPods会帮我们处理这种依赖。但由于EC3rdFramework并非已经发布的第三方库，如果不加上这一句的话，在pod install时会出现下面的错误：

[!] Unable to find a specification for EC3rdFramework depended upon by ECSDK

CocoaPods会去已经发布的库中去寻找，而不是本地。同时由于CocoaPods也不支持在podspec中像Podfile中一样，通过:path => ../EC3rdFramework指定本地路径，StackOverflow这里有讨论，所以采用这种变通方法。但这并不影响我们演示。

在ECApp路径下执行pod install之后，然后编译运行，将会得到以下日志：

2016-02-16 21:27:32.032 ECApp[30005:1064278] running in app env
2016-02-16 21:27:32.032 ECApp[30005:1064278] running on simulator

表示库已经正常调用，运行于App环境中的模拟器上。我们需要进行单元测试的开发环境搭建完成。

添加单元测试

环境搭好之后，接下来，为ECSDK添加单元测试。由于Xcode集成了XCTest，所以添加单元测试非常简单，依次选择菜单项：New/Target/iOS/Test/iOS Unit Testing Bundle，这里我们的测试target为ECSDKTests。完成后，在ECSDK工程中会生成对应的target和源文件，可以看到工程中有一个ECSDKTests.m文件，这是Xcode默认生成的测试用例，是来打酱油的，什么事都没做。选中ECSDKTests这个Scheme，按下⌘ U(注意，这里是U，而不是平时所用的B和R)编译并运行测试，因为此时是默认的空测试用例，所以测试很顺利的完成：

编写测试用例

为了测试ECSDK中提供的方法，我们需要为其添加新的测试用例。三种场景，只有返回YES时才算通过测试，由此表示测试可以运行于这些环境中：

// ECSDKTests.m
#import "ECUsingFoo.h"
// ...
- (void)testMethodDependsOnNothing {
    ECUsingFoo *foo = [ECUsingFoo new];
    XCTAssert([foo methodDependsOnNothing], @"The method must be running in ANY env");
}

- (void)testMethodDependsOnAppEnv {
    ECUsingFoo *foo = [ECUsingFoo new];
    XCTAssert([foo methodDependsOnAppEnv], @"The method must be running in app env");
}

- (void)testMethodMustBeRunningOnDevice {
    ECUsingFoo *foo = [ECUsingFoo new];
    XCTAssert([foo methodMustBeRunningOnDevice], @"The method must be running on device");
}

测试用例很简单，我们来看看是否可以运行。再次选中ECSDKTests这个Scheme，⌘ U编译运行，此时出现以下错误：

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_ECUsingFoo", referenced from:
      objc-class-ref in ECSDKTests.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

错误信息显示链接时找不到ECUsingFoo方法，后者是定义在ECSDK工程中，表示测试target需要依赖ECSDK。处理依赖有多种方法：可以在Build Settings中添加库及其对应路径。还有一种更好的办法，利用CocoaPods，在它的Podfile中增加一个target即可，这样可以保证ECSDKTests和ECSDK的依赖完全一致。新的Podfile像这样：

def import_common_pods
    pod 'EC3rdFramework', :path => '../EC3rdFramework'
end

target "ECSDK", :exclusive => true do
    import_common_pods
end

target "ECSDKTests", :exclusive => true do
    import_common_pods
    pod 'ECSDK', :path => '.'
end

因为依赖了共同的库，所以将这抽出来成为一个单独的方法，接着在两个target中调用。由于测试target是依赖于ECSDK，所以还需要加上：pod 'ECSDK', :path => '.'。重新pod install，⌘ U，编译问题解决，测试可以正常运行。

但现在面临两个新的问题，因为现在测试只能运行于模拟器上，而且并非是App的环境，所以后面两个测试无法通过。

如果我们直接将Scheme选成真机上运行，一按⌘ U便会弹出以下错误提示：

> Logic Testing on iOS devices is not supported. You can run logic tests on the Simulator.

暂时无法运行于真机上。

让测试运行在App环境

我们先来看如何让测试运行于App环境中。Apple在开发文档中提过两个概念，一个叫Logic Tests，另外一个叫Application Tests，前者表示简单的逻辑测试，只能够运行在模拟器中，我们刚创建的测试target正是前面一种。这也是为何选择真机时，会弹出上面错误提示的原因。

文档中提到了如何配置Application Tests的方法，但是很遗憾，因为这篇文档是针对旧的OCTest框架，现在Xcode采用了新的XCTest框架，所以已经是”Retired”状态：

Retired Document

Important: This version of Unit Testing Guide has been retired. The replacement document focuses on the new testing features and workflow provided by Xcode 5 and later revisions. For information covering the same subject area as this page, please see Testing with Xcode.

新的文档中也没有再提这两个概念。但由于XCTest的前身就是OCTest，是否配置的方法也是相通的？是否将测试target变成Application Tests之后，就可以运行在App环境中？抱着试一试的想法，按照废弃文档中的方法来配置测试target。

在General配置页面，里面有一个Host Application，这个便表示测试是否可以运行于App中。但由于当前测试的是一个静态库，无法选择想要运行的App，此时需要用通过其它途径来指定。在ECSDKTests的Build Settings中修改两处：

  1. Bundle Loader: Your/App/Path/ECApp.app/ECApp
  2. Test host: $(BUNDLE_LOADER)

再次运行，发现ECApp的应用先启动，随后测试用例开始执行。因为ECApp在启动之后便配置了App环境的标志位，所以环境依赖的测试用例可以正常通过，测试已经可以运行于App的环境中，我们的尝试成功了。现在只剩下最后一个场景，如何让测试运行于真机上：

让测试运行在真机上

其实，在完成上一步的配置之后，测试已经从所谓的Logic Tests就转变成了Application Tests，而后者对运行的环境是没有限制的。直接将Scheme设置成真机，先编译一下ECApp，再运行一次测试，所有的测试可以通过：

特殊情况

注意：事情并不会总是这么顺利，有时候由于一个App过于庞大，各个库的podspec写得不是很规范，不是所有依赖的Libraries都写在了podspec中，有些被放在Build Phases里面，系统库尤为常见。这样就导致即使我们按照前面介绍的都配置好了，还是无法让测试target编译通过，在链接时会出现各种各样的找不到符号的错误。此时需要手动去添加这些库到测试target的Build Phases中。至于需要添加哪些，只有根据编译时的错误逐一添加了。而且有一点需要注意：有时库的Status需要是Optional，否则最后链接的时候也会出错。下面是一个真实测试用例在Build Phases中所依赖的库：

它一共依赖了41个系统库，每一个都是在编译出错时，查到缺少的符号所在的库来添加的，是个体力活:-)。

结尾

至此，我们的测试用例已经可以运行于上面描述的几种典型的复杂环境，其实最重要的步骤只有两步，第一步是设置依赖，处理各种编译错误；第二步是设置Build Settings，将测试转成Application Tests，让测试能够运行于App环境。

我们搭建的环境和真实的环境相比起来，复杂度还存在一定的差距，在编译测试target时会出现各种各样奇怪的问题，本文无法一一例举，靠大家根据实际情况处理了。

如果想对Xcode的测试有一个系统的了解，强烈建议大家去阅读文档Testing with Xcode，非常详细的介绍了用Xcode进行测试的方方面面。

新的一年，以这篇简单的文章作为起始，祝大家新年快乐！

(全文完)

时间： 2024-04-27 01:54:07

iOS中如何对具有复杂依赖的SDK在真机上进行单元测试的相关文章

iOS中 最新微信支付／最全的微信支付教程详解

版权声明:本文为博主原创文章,未经博主允许不得转载. 每日更新关注:http://weibo.com/hanjunqiang  新浪微博! 亲们, 首先让我们来看一下微信支付的流程吧. 1. 注册微信开放平台,创建应用获取appid,appSecret,申请支付功能,申请成功之后会返回一些参数. 2. 下载微信支付sdk 3. 客户端请求订单,后台与微信后台交互,返回给客户端支付参数 4. 调用微信客户端,由微信客户端和微信服务器打交道: 5. 客户端和服务端都会收到支付结果:(前台消息不可靠,

iOS中制作可复用的框架Framework

iOS中制作可复用的框架Framework         在iOS开发中,我们时常会使用一些我们封装好的管理类,框架类,方法类等,我们在实现这些文件时,可能还会依赖一些第三方库或者系统库.如果每次我们复用这些代码时,都要将关联的这些东西进行导入,甚至还要进行arc和mrc的编译设置,会浪费我们很大的精力.除此之外,如果项目需要多人合作,你可能也并不希望你的源代码暴漏在所有人的面前,这个时候,我们就可以使用静态库或者动态库的方式来对我们的代码进行包装,便于复用.静态库的制作方法在一篇旧的博客中有

浅析iOS中的浅拷贝和深拷贝(copy和mutableCopy)_IOS

ios提供了copy和mutablecopy方法,顾名思义,copy就是复制了一个imutable的对象,而mutablecopy就是复制了一个mutable的对象. copy与retain的区别: copy是创建一个新对象,retain是创建一个指针,引用对象计数加1.Copy属性表示两个对象内容相同,新的对象retain为1 ,与旧有对象的引用计数无关,旧有对象没有变化.copy减少对象对上下文的依赖. retain属性表示两个对象地址相同(建立一个指针,指针拷贝),内容当然相同,这个对象的

iOS 中的 21 种设计模式

iOS 中的 21 种设计模式 对象创建原型(Prototype) 使用原型实例指定创建对象的种类,并通过复制这个原型创建新的对象. 1 2 NSArray *array = [[NSArray alloc] initWithObjects:@1, nil]; NSArray *array2 = array.copy; array 就是原型了,array2 以 array 为原型,通过 copy 操作创建了 array2. 当创建的实例非常复杂且耗时,或者新实例和已存在的实例值相同,使用原型模式

iOS中线程Call Stack的捕获和解析（二）

上接iOS中线程Call Stack的捕获和解析(一). 1. 部分参考资料 做这一块时也是查阅了很多链接和书籍,包括但不限于: <OS X ABI Mach-O File Format Reference> <Mach-O Programming Topics> <程序员的自我修养>--这本几年前读过的,又一次从书架上拿下来温习,主要是用来对比确认: <The Mac Hacker's Handbook> <Mac OS X and iOS Inte

iOS中 最新微信支付／最全的微信支付教程详解 韩俊强的博客

亲们, 首先让我们来看一下微信支付的流程吧. 1. 注册微信开放平台,创建应用获取appid,appSecret,申请支付功能,申请成功之后会返回一些参数. 2. 下载微信支付sdk 3. 客户端请求订单,后台与微信后台交互,返回给客户端支付参数 4. 调用微信客户端,由微信客户端和微信服务器打交道: 5. 客户端和服务端都会收到支付结果:(前台消息不可靠,我们需要去后台验证,如果后台没有收到支付通知,后台去微信服务器验证然后将结果返回给客户端) 支付流程图(大家看一下支付流程). 那么我们现在

iOS中几种数据持久化方案：我要永远地记住你！

概论 所谓的持久化,就是将数据保存到硬盘中,使得在应用程序或机器重启后可以继续访问之前保存的数据.在iOS开发中,有很多数据持久化的方案,接下来我将尝试着介绍一下5种方案: plist文件(属性列表) preference(偏好设置) NSKeyedArchiver(归档) SQLite 3 CoreData 沙盒 在介绍各种存储方法之前,有必要说明以下沙盒机制.iOS程序默认情况下只能访问程序自己的目录,这个目录被称为"沙盒". 1.结构 既然沙盒就是一个文件夹,那就看看里面有什么吧

iOS中关于模块化开发解决方案(纯干货)_IOS

关于iOS模块化开发解决方案网上也有一些介绍,但真正落实在在具体的实例却很少看到,计划编写系统文章来介绍关于我对模块化解决方案的理解,里面会有包含到一些关于解耦.路由.封装.私有Pod管理等内容:并编写的一个实例项目放在git进行开源[jiaModuleDemo],里面现在已经放着一些封装的功能模块:会不断的进行更新,假如你感兴趣可以Star一下,项目也不断的更新完善优化:如果你有更好的方案或者说好的建议可以lssues,我会在短时间进行更新并修改相应的问题: 一:项目中存在的问题 1:当公司里

在IOS中为什么使用多线程及多线程实现的三种方法_IOS

多线程是一个比较轻量级的方法来实现单个应用程序内多个代码执行路径. 在系统级别内,程序并排执行,程序分配到每个程序的执行时间是基于该程序的所需时间和其他程序的所需时间来决定的. 然而,在每个程序内部,存在一个或者多个执行线程,它同时或在一个几乎同时发生的方式里执行不同的任务. 概要提示: iPhone中的线程应用并不是无节制的,官方给出的资料显示,iPhone OS下的主线程的堆栈大小是1M,第二个线程开始就是512KB,并且该值不能通过编译器开关或线程API函数来更改,只有主线程有直接修改UI