BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

iOS开发中的单元测试(二)——让断言活泼起来的匹配引擎

| 作者 高嘉峻 关注 2 他的粉丝 发布于 2013年6月21日. 估计阅读时间: 19 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

上一篇文章简单介绍了OCUnit和GHUnit两款iOS开发中较为常见的单元测试框架,本文进一步介绍单元测试中的另一利器——匹配引擎(Matcher Engine)。匹配引擎可以替代断言方法,配合单元测试引擎使用,测试用例可以更多样化,更细致。

传统断言提供的方法数量和功能都有限,以导读中提到的两款框架为例,即使是断言相对丰富的GHUnit也只是提供了38种断言方法,范围仅涵盖了逻辑比较,异常和出错等少数几方面,仍然很单一。而使用匹配引擎代替断言,可能性就大大丰富了,除了普通断言支持的规则,一般的引擎还默认提供了包含,区间,继承关系等。更重要的是,使用匹配引擎开发者可以自行开发匹配规则,引入与业务相关的逻辑判断。

本文要介绍两款匹配引擎,一款就是Hamcrest的Objective-C实现——OCHamcrest,另一款则是专为Objective-C/Cocoa而生的后来者——Expecta。接下来将结合GHUnitTest,介绍两款匹配引擎如何在单元测试中发挥作用(有关GHUnitTest参考《iOS开发中的单元测试(一)》

OCHamcrest

介绍匹配引擎必须要提Hamcrest,几乎已经成为匹配引擎的代名词。官网首页上的一句话表明了它的身世:“Born in Java, Hamcrest now has implementations in a number of languages.”。这款诞生于Java的匹配引擎现在还支持除Java的Python、Ruby、PHP、Erlang和Objective-C。

  • 加入工程

在iOS工程中使用OCHamcrest需要先获取OCHamcrestIOS.framework,可以从Quality Coding直接下载,或在Github上获取源码编译。注意:Github上托管的OCHamcrest工程以Submodule的形式关联源代码,因此如果使用命令行方式clone工程,需要执行“git submodule update --init”。

下载源码后,进入Source目录,执行MakeDistribution.sh脚本,将会在Source/build/Release下生成OCHamcrest.framework、OCHamcrestIOS.framework和OCHamcrest.framework.dSYM , OCHamcrestIOS.framework就是iOS工程中需要用到的框架,如图1。

图1,从源码编译生成 OCHamcrestIOS.framework

打开已经安装了GHUnitTest的工程,把OCHamcrestIOS.framework添加到单元测试的Target中。在需要使用匹配引擎的用例中,定义“HC_SHORTHAND”并导入“<OCHamcrestIOS/OCHamcrestIOS.h>”(如图2)。

图2,把OCHamcrestIOS.framework导入工程

至此OCHamcrest已经安装完成,可以再测试用例中使用匹配规则代替GHUnitTest的断言方法。

  • 预定义规则

OCHamcrest针对不同的数据类型提供了大量的预定义匹配规则,大大丰富了断言的类型。支持的数据类型包括:对象、容器、数值和文本,此外还提供了专门的逻辑匹配规则。

以文本(一般就是NSString)为例,OCHamcrest提供了6种针对对象的匹配规则:

IsEqualIgnoringCase,该文本是否与给出的文本相同(忽略大小写);

IsEqualIgnoringWhiteSpace,该文本是否与给出的文本相同(忽略空格);

StringContains,该文本是否包含给出的文本片段;

StringContainsInOrder,该文本是否按照先后顺序包含给出的若干文本片段;

StringEndsWith,该文本是否以给出的文本片段结尾;

StringStartsWith,该文本是否以给出的文本片段开头。

另外,再举OCHamcrest为对象(NSObject和NSObject的子类)预定义的8条规则:

ConformsToProtocol,该对象是否遵循了给出的协议,或者说是否实现了给出的Delegate;

HasDescription,允许使用文本规则对给出的一段文本与该对象的描述进行匹配;

HasProperty,该对象是否含有给出的属性;

IsInstanceOf,是给出的类的实例,或是给出的类子类的实例;

IsTypeOf,是给出的类的实例,不同于IsInstanceOf,无法匹配子类实例;

IsNil,为空;

IsSame,与给出的对象是同一个实例。

  • 撰写用例

OCHamcrest提供了匹配规则和相应的断言方法,配合单元测试框架(本文以GHUnit为例, 在《iOS开发中的单元测试(一)》中已经介绍了如何安装GHUnit框架并撰写用例)的驱动机制即可撰写用例。本文以联合使用上述提到的StringStartsWith和HasDescription规则为例。

首先,定义一个用于示例的类“Man”(如图3),有属性friends,当friends为空,其description为“Man without any friend, so sorry.”,反之为“Nice persion with [friends count] friend(s).”。(使用Foo或Bar这样的示例会显得很没情怀吧 ;-|)

图3,用于测试的类:Man

用例中判断某Man实例的description是否以Nice开头(这是不是一个友善的人),如图4。

图4,测试用例两则

UntTestCase是GHTestCase的子类,引入<OCHamcrestIOS/OCHamcrestIOS.h>并定义HC_SHORTHAND表示使用OChamcrest。setUp方法在每个测试方法执行之前初始化一个Man实例;testANiceMan方法向Man实例的friends属性中加入两个值,因此该实例的description将返回“Nice man ....”;使用OCHamcrest提供的断言方法assertThat与匹配规则配合,判断该实例的description是否以“Nice”开头;testNotANiceMan方法则直接测试一个未经过加入friends的实例测试。

上述测试,testANiceMan方法顺利通过,testNotANiceMan不会通过,直接报出错误堆栈,并打印在匹配规则中预先定义好的出错信息(如图5)。

图5,测试结果

  • 辅助方法

Syntactic Sugar是一种提高匹配规则和断言可读性的方案,让一个匹配和断言看起来更像是一句自然语言的话,而非多个函数的堆砌,对实际的匹配运算不产生任何影响。例如,没有加Sugar的匹配:

assertThat(foo, equalTo(bar));

加Sugar可以是:

assertThat(foo, is(equalTo(bar)));

除了Sugar,OCHamcrest还提供了describedAs方法,用于辅助断言方法,自定义出错文案,例如:

assertThat(foo, describedAs(@”foo should be equal to bar”, equalTo(bar), nil));
  • 自定义规则

OCHamcrest官方给出的自定义匹配规则示例是:onASaturday,判断一个NSDateComponents实例是否为星期六。本文以上一节使用的Man对象为例,匹配某Man实例是否有一个名为“Joe”的好友,规则命名为:hasAFriendJoe。

自定义匹配规则包括两部分,一个Macher类和一个用OBJC_EXPORT方式定义的函数。

自定义Macher类都是HCBaseMatcher的子类(如图6),接口中定义的类初始化方法供匹配方法hasAFriendJoe调用,其实现则通过调用接口中定义的另一个实例方法。

图6,HasAFriend接口和匹配方法hasAFriendJoe定义

在HasAFriend中需要引入<OCHamcrestIOS/HCDescription.h>,并重写父类中的matches:和describeTo:方法(如图7)。在maches:方法中实现匹配逻辑,匹配成功则返回YES,否则返回NO;describeTo是失败后的描述;hasAFriendJoe方法只需要调用类方法初始化匹配规则类即可。匹配规则定义后,可以配合断言方法使用,如上一节所示的assertThat方法:

assertThat(self.man, hasAFriendJoe());

图7,规则实现

Expecta

Expecta专为Objective-C/Cocoa而生,相比OCHamcrest,其优化了匹配的语法,测试用例的可读性更高。此外,Expecta对匹配对象类型没有强制要求,允许任意类型的数据进行匹配。在OCHamcrest中每一条匹配规则都是一个方法,规则联合使用也需要以参数形式传递。在Expecata中联合规则的语法是以点号连接,借助Sugar介词可以把一个联合规则拼装成一句符合自然语法的句子,例如:

OCHamcrest —— assertThat(@"foo", is(equalTo(@"foo")));
Expecta —— expect(@"foo").to.equal(@"foo");
  • 加入工程

Expecta提供了CocoaPods的源,可以通过定义依赖引入:

dependency 'Expecta', '~> 0.2.1'

dependency 'Specta', '~> 0.1.7' # specta bdd framework

或者从github上获取源代码,编译出Library,引入XCode工程。下载源码后,进入工程目录,运行rake,编译工程。编译完成后,把products目录拷贝到工程中(如图8),在iOS/MacOSX工程中加入响应的.a文件(如图9)。在Build Settings的Other Linker Flags中加入-ObjC参数(在《iOS开发中的单元测试(一)》中添加GHUnit一节介绍了如何添加-ObjC的参数)。与OCHamcrest类似,在测试用例中定义EXP_SHORTHAND,并引入“Expecta.h”(如图10)。

图8,加入编译后的头文件列表

图9,加入Library文件

图10,用例中引入Expecta

  • 预定义规则

Expecta提供的预定义规则只有20条,远远少于OCHamcrest提供的预定义规则。由于Expecta的匹配规则对匹配对象没有要求,因此没有提供像OCHamcrest中针对某种对象的特定规则。

在Expecta的github首页可以看到全部预定义规则列表。举几个较有特点的规则为例:

expect(x).to.beCloseToWithin(y, z),x距离y的距离小于z
expect(x).to.beTruthy(), x是否为真(或非空);
expect(x).to.beFalsy(),x是否为假(或空/零);
expect(^{ /* code */ }).to.raiseAny(),该Block是否抛出异常;
expect(^{ /* code */ }).to.raise(@"ExceptionName"),该Block是否抛出给定名字异常。

此外,通过.notTo或.toNot对规则取反进行匹配,如:expect(x).notTo.equal(y)。

通过.will或.willNot进行异步匹配,即在超时时间(默认超时1秒,也可通过[Expecta setAsynchronousTestTimeout:x]设定)之前满足匹配规则即可,如:expect(x).will.beNil()。

  • 撰写用例

Expecta不使用类似assertThat类似的辅助断言方法,而是直接使用expecta.语法匹配。

仍然以GHUnit测试用例为例,测试一个数字n,是否在5附近,距离小于2,即处在[3,7]区间内(如图11)。

图11,Expecta测试用例

Expecta不支持匹配规则的联合使用。

  • 辅助方法

Expecta也有语法Sugar:to。

  • 自定义规则

Expecta的自定义规则有两种方式,静态规则和动态规则。

定义静态规则:

Expecta的匹配规则不是一个类,是通过框架提供的宏定义来实现的,操作比定义OCHamcrest规则简单不少。仍以OCHamcrest中的判断一个Man实例是否有名为“Joe”的好友。

通过EXPMatcherInterface()方法定义,该方法有两个参数,规则名和规则参数列表。示例如图12。

图12,扩展规则hasAFriendJoe定义

EXPMacherInterface第二个参数允许通过这样的方式定义列表:(NSString *Foo, int bar)。

在实现中,用EXPMatcherImplementationBegin和EXPMatcherImplementationEnd标示规则实现的头尾。并定义prerequisite、match、failureMessageForTo和failureMessageForNotTo四个Block,分别返回与判断结果,匹配结果,正向匹配出错原因和反相匹配出错原因(如图13)。由于Expecta框架不支持ARC,因此需要在Build Settings中对该.m文件添加 -fno-objc-arc参数。在测试用例中可以通过如下语法调用:

expect(self.man).hasAFriend(@"Joe");

或反相匹配:

expect(self.man).notTo.hasAFriend(@"Joe");

图13,Expecta自定义规则实现

定义动态规则:

动态规则是本质上并不是一段逻辑匹配,而是通过Expecta的语法对匹配对象的属性进行是否为真的断言。例如:

@interface LightSwitch : NSObject
@property (nonatomic, assign, getter=isTurnedOn) BOOL turnedOn;
@end
@implementation LightSwitch
@synthesize turnedOn;
@end

可以写出如下断言:

expect([lightSwitch isTurnedOn]).to.beTruthy();

建立动态规则:

EXPMatcherInterface(isTurnedOn, (void));

就可以通过以下断言判断turendOn属性的真假:

expect(lightSwitch).isTurnedOn();

总结

整体看两款匹配引擎,Expecta小巧,敏捷,提供了多种灵活的匹配方式,OCHamcrest从Hamecrest体系继承而来,形式更加中庸,提供的机制更完善。从开发者的角度看,Expecta更好玩,而OCHamcrest更实用,在实验性的项目中我会偏向选择Expecta,而较正式的项目则会使用OCHamcrest。

OCHamcrest结合上一篇《iOS开发中的单元测试(一)》中介绍的单元测试框架GHUnit可以给开发者提供一个完整的单元测试方案,建议开发者在自己的项目中引入这样的质量自控机制,写出健壮的代码。

通过两篇文章介绍了单元测试框架和匹配引擎的一些基础知识,在接下来的文章中,我将结合一个项目,从实战角度详细记述如何开发带有单元测试的iOS项目。

作者简介:

高嘉峻(微博:@gaosboy),SegmentFault.com联合创始人,杭州iOS开发者沙龙发起人,资深iOS开发者。


感谢李永伦对本文的审校。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT