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</pre>    </div>      
开发中的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];  }</pre>    </div>      
同前面类似，它的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</pre>    </div>      
也是因为这个依赖，还需要一个Podfile：
      
     
target "ECSDK" do    pod 'EC3rdFramework', :path => '../EC3rdFramework'  end</pre>    </div>      
最终应用：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;  }</pre>    </div>      
 方法的前两行，先设置了App环境的标识，前面 ECFoo 中便是依赖于此标识来判断是否处于App的环境中。 
      
它的Podfile也很简单：
      
     
target "ECApp" do    pod 'EC3rdFramework', :path => '../EC3rdFramework'    pod 'ECSDK', :path => '../ECSDK'  end</pre>    </div>      
 这里有一点需要注意的是，实际上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");  }</pre>    </div>      
 测试用例很简单，我们来看看是否可以运行。再次选中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</pre>    </div>      
 因为依赖了共同的库，所以将这抽出来成为一个单独的方法，接着在两个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中修改两处：
      
     
Bundle Loader: Your/App/Path/ECApp.app/ECApp
       
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进行测试的方方面面。 
      
新的一年，以这篇简单的文章作为起始，祝大家新年快乐！
      
(全文完)
      
feihu2016.02.17 于 Shenzhen 
   </code></code></code></code></code></code></code></code></div>


            

                
 本文由用户 MissPuff  自行上传分享，仅供网友学习交流。所有权归原作者，若您的权利被侵害，请联系管理员。
                
 转载本站原创文章，请注明出处，并保留原始链接、图片水印。
                
 本站是一个以用户分享为主的开源技术平台，欢迎各类分享！
                
 本文地址：https://www.open-open.com/lib/view/open1455759706651.html
                
 iOS开发 单元测试 移动开发