“我非常确信，在我有生之年，对软件发展的最大贡献不是来自面向对象方法和高级语言、函数式编程、强类型、MVC 或其他任何东西，而是来自测试文化的兴起。”单元测试，是针对一小段代码或方法，检验被测代码一个小的、明确的功能是否正确 ，证明某段代码的行为和开发者期望一致的行为。简单来说，是针对单个程序、函数、过程进行正确性检验的工作的白盒测试。独立（Independent）测试应该相互独立，不能有依赖。可重复（Repeatable）测试应当可在任何环境重复通过。包括无网络的环境。自足验证（Self-Validating）测试应该有布尔值输出。及时（Timely）测试应及时编写。单元测试应该恰好在使其通过的代码之前编写。一个成熟的软件开发人员非常清楚测试的重要性。当我们需要开发一个新功能、新需求时，我们通过单元测试来验证一段代码中是否运行的正常，传入极端边界值是否会出现问题，单元测试还能使第一次阅读代码的开发人员更好的理解这段代码的含义。经过良好的的单元测试过的代码总会给开发人员带来勇气。当我们需要重新修改需求、甚至重构代码时，因为有了良好的单元测试，即使你搞砸了，你也会很快通过运行不通过的单元测试发现问题。所以单元测试，前端和后端都很重要，现在和以后都很重要。开发成本增加。TDD原则要求我们在开发代码前先编写单元测试，按照这条规则，我们编写的单元测试将覆盖所有业务代码。测试的代码量足以匹敌需求代码量，编写单元测试所需要花费的时间将和开发需求的时间相同甚至远超开发时间，这无疑增加了开发人员的开发成本。无法验证单元测试的有效性。基于控制唯一变量的原则，如果要验证单元测试的有效性，我们需要找到两个强大的团队来执行重要的开发任务，并且在规模、结构、工具、技能水平和工作实践——在除测试之外的所有方面的表现都大致相同。然后，还需要在一个比较长的周期内研究他们的生产力和质量差异。无疑还没有团队能够这样去做，所以我们无法使用有效的数据来说明单元测试的有效性，只能凭借以往开发者的经验积累来进行单元测试。在阿波罗早期调研时，公司内部还没有太多的方案可供选择。所以我们主要是使用手动导入XCodeCoverage和OCMock库再接入Bamboo的方案。现在iBiu最新版本已经支持了单元测试，内部也是使用XCodeCoverage库来生成覆盖率。
那么就先针对这两个平台对现有的单测支持能力做一个对比：
1. 如果你现在已经接入了iBiu，但是现在不是太着急生成视图的单测覆盖率报告，可以先使用Xcode的自带单测覆盖率查看，等iBiu与Bamboo数据打通后直接通过iBiu接入。（两个团队已经在紧急建设中）2. 如果部门需要统一在Bamboo中统计单侧覆盖率，那么可以直接使用手动接入Bamboo方式，除了第一次配置略麻烦，后面直接在Bamboo定时运行还是很方便。3. 如果你的工程没有接入iBiu，或者还不想接入Bamboo，但是想要生成更加详细的单测覆盖率，可以只接入XCodeCoverage和OCMock，生成本地单测详细报告。iBiu接入和Bamboo中生成单测覆盖率报告都是使用XCodeCoverage，下文会详细介绍这个库的使用方法。无论在iBiu、还是Bamboo，我们关注的有效数据都是单元测试覆盖率。
无论是哪种方式接入，单测覆盖率最终的数据来源都是通过Xcode生成。
2. 开启覆盖率需要覆盖的范围，选择你需要测试target，一般是我们的组件源码所在的target；
4. 写好单测代码，运行command+U后，就可以看到生成的单测覆盖率
5. 点开详细内容，可看到具体哪些代码被覆盖，其中红色代表没有被覆盖，绿色代码已经被覆盖。
当每一次运行单测后，都应该快速的点开浏览所有重要的代码块，查看被覆盖和没被覆盖的部分。往往有些你觉得单元测试已经被覆盖到的部分，其实并没有覆盖到。一般来说，单测覆盖率不会达到100%。阿波罗前端本次接入单测只考虑业务逻辑的代码部分，UI单测并不在本次的规划当中，所以我们的单测覆盖率对比服务端相对会更低一些。XcodeCoverage提供了一种简单的方法来生成Xcode项目的Objective-C代码覆盖率报告。生成的报告包括HTML和XML。覆盖数据不会包括苹果sdk，并且XcodeCoverage现在还不支持Swift。- 如果工程是使用iBiu，那么在Podfile文件平级的文件夹中，新增一个Podfile.custom文件，然后使用iBiu进行安装。
文件内容：
- 如果工程没有使用iBiu，那就使用CocoaPods正常安装，在Podfile文件中增加pod 'XcodeCoverage'，然后pod install。
xcpretty用于对xcodebuild的输出进行格式化。并包含输出report功能。
ocunit2junit用来将 OCUnit 的输出转换成 JUnit 风格的报告在你的主工程中加一个Run Script，运行一个脚本文件${PODS_ROOT}/XcodeCoverage/exportenv.sh
打开一下要运行的脚本，文件就在Pod/XcodeCoverage/下
主要作用是新生成了一个env.sh文件，并写入了BUILT_PRODUCTS_DIR、CURRENT_ARCHOBJECT_FILE_DIR_normal、OBJROOT、OBJROOT等参数。然后我们先command+b或者command+u一下，运行这个脚本去生成env.sh。打开生成的env.sh脚本看一下
- OBJECT_FILE_DIR_normal，这个值默认生成的是我们主工程的地址，但是现在我们要测试的是包含业务代码的target，所以这个值需要修改为目标target的地址。
我们真正的代码其实在工程中是相当于一个pod，所以这个值需要改成Pod所在的位置/Users/xxxx /Library/Developer/Xcode/DerivedData/xxxCartModule-gtprkfazpqerpsczqxftrlwkzauw/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/xxxCartModule.build/Objects-normal。需要注意，因为env.sh是由于run exportenv脚本每次动态生成，就会导致每次build或者跑单测都会生成一次，都需要改一次上述的两个值。如果觉得比较麻烦可以写一个脚本进行修改。修改完成后我们cd到Pods/XcodeCoverage文件夹，执行getcov脚本。/getcov -s,运行后，浏览器会自动打开生成的单测覆盖率详细报告。生成的报告包含总代码行、已覆盖的代码行、代码覆盖率、总方法数、已覆盖的方法数、方法覆盖率，可以点击每一个类查看覆盖的代码和没有覆盖的代码。如果想要将单测报告生成到指定文件夹，可以执行
Xcode编译后会为每个可执行文件生成对应的 .gcno 文件；之后在代码中调用覆盖率分发函数，会生成对应的 .gcda 文件。其中，.gcno 包含了代码计数器和源码的映射关系， .gcda 记录了每段代码具体的执行次数。覆盖率解析工具都需要结合这两个文件给出最后的检测报表。这就是为什么我们需要修改env.sh中的文件路径，因为需要让XcodeCoverage去扫描正确的gcda 文件。刚刚在终端运行生成单测覆盖率时的输出记录可以验证以上内容。
在生成覆盖率报告的日志中，我们还会发现有类似这样的输出：像我的工程输出这个报错是因为在代码中使用了外部类的一个方法。
一般我们工程中会引用到许多JD内部库，除了上面的运行错误日志外，还会导致无法生成最后的单测报告文件：
解决办法是：需要让XcodeCoverage在扫描文件的时候忽略掉JD库，在Classes下新增一个.xcodecoverageignore文件，文件内容中写要忽略的库就可以了。${SRCROOT}/报错的库 /*
- `--show` or `-s`: Show HTML report.
- `--xml` or `-x`: Generate Cobertura XML. 生成覆盖率XML
- `-o output_dir`: Specify output directory. 将结果输出到一个文件夹
- `-i info_file`: Specify name of generated lcov info file. 指定生成的lcov信息文件的名称
- `-v`: Enable verbose output.
- `-h` or `--help`: Show usage.
当通过以上步骤本地工程可以正常生成覆盖率报告文件时，接入Bamboo就变得非常容易。开发测试代码和开发需求代码一样重要。测试必须跟随业务代码的修改而修改，它不是一次性的产物，也需要开发人员进行维护。下面表格列举出一个工程中主要部分和是否需要单元测试，供大家参考：
写单元测试应该在代码开发之前，且应该自下向上进行，从最基础的开始写。
Given：配置测试的初始状态，比如造一些数据、mock一些对象等，这里我们可能需要OCMock这个库的辅助。When：对要测试的目标执行代码，调用你要测试的方法Then：对测试结果进行断言（成功 or 失败），对于结果做一个预判，并且通过编译来判断你的预判是否正确。
一个单测类只测一个代码类。一个单测类中只测试这个类的相关方法，不要把所有的单测方法都写在一个测试类中。这样看上去拥挤不堪，既不美观又不好维护。并且注意命名规则，可以是被测试的类名+Test。一个单测方法只测一个方法的一种情况。我们不要想写一个超长的测试方法，在同一个方法里测试完这个又测试那个，就像下面这种，需要拆分成两个单测方法。当然一个方法中可以针对一种情况写多条断言。
如果你需要测试定义在.m中的一个方法或者一个属性。可以在单测的target中，创建一个Category，将私有的方法和属性开放到.h中。并且可以将Category的.m文件删除，它并没有什么用。
单元测试中如何mock数据？
举个例子，业务代码如下，单元测试需要验证是否走到了if里：
方式1：模拟一份假数据当做入参
方式2：你当然可以不关心假数据是什么，只关注这个方法中的逻辑。那就使用OCMock直接存根一份对象。
具体选择哪种方式可以根据被测试的方法自行判断：如果入参是一个对象，那么选择OCMock；如果入参是一个基础数据，造假数据比较麻烦可以选择OCMock，假数据结构不麻烦的话可以直接mock假数据。需要特别关注断言失败的单测，这可能证明你对你的代码有某些误判。苹果提供了断言XCTAssert等方法，具体如下：
从以上表格中可以看到苹果提供的基本是对变量的判断。当我们需要校验的是最后是否跳转到另一个方法时，就需要使用OCMock的OCMVerify方法。OCMock实际是利用runtime原理，通过消息转发方式来实现的。感兴趣的同学可打开源代码看一看。
1. OCMock生成的对象是id类型，在使用mock对象的时候，调用属性名和方法名都不会自动带出，所以调用的方法名需要自己写出来。
3. 在使用断言方法判断一个方法时，如果方法有入参，可以使用[OCMArg any]当做入参，该方法可以返回一个id类型的参数，这样无需纠结入参的值，需要注意int、float等类型不可以使用。如果在断言方法时代码明明走到了单测依旧报错，可以校验下方法中的传参是否相同。
4. 使用OCMock时，最好在每次使用完后手动调用stopMocking，养成用完即释放的好习惯
以上就是OCMock经常使用的方法，建议在使用时看看官方文档《OCMock》关于OCMock的实际用法还可以参考《OCMockTests》。阿波罗平台致力于提供多端、全流程的交易解决方案，帮助用户快速搭建交易类的APP和小程序，并且具备一定的组件配置和共建能力，满足业务需求。
内部员工详细资料请在神灯查阅。
21520浏览
