This action will force synchronization from KevinHM/FunctionalReactiveProgrammingOniOS, which will overwrite any changes that you have made since you forked the repository, and can not be recovered!!!
Synchronous operation will process in the background and will refresh the page when finishing processing. Please be patient.
本书的最后一节,我们谈谈测试,尤其是单元测试。在iOS的开发社区里,这是一个有争议的话题,这也是为什么我要把它放在最后的原因。理想的情况下。你应该在编写视图模型的同时为它编写单元测试。然而学习如何使用这种新的模式来编码已经很困难,尝试去测试这些你没有吃透的东西,多你来说压力太大,所以我把它放在了最后(学到这里我相信你已经理解了这种编码方式)。
当然我也注意到,并不是每个人都以相同的方式来测试,或者能够测试到相同的程度。我有.Net编程背景,在.net中使用mocks来测试系统的实现细节是最平常不过的了。其他平台背景的开发者较少使用mocks来做,甚至从来没有这样的经验。本节我只将我的单元测试方法分享给大家,如果你觉得合适就采用。
确保你的Podfile
文件包含下面这些库:
target "FRPTests" do
pod 'ReactiveCocoa', '2.1.4'
pod 'ReactiveViewModel', '0.1.1'
pod 'libextobjc', '0.3'
pod '500px-iOS-api', '1.0.5'
pod 'Specta', '~> 0.2.1'
pod 'Expecta', '~> 0.2'
pod 'OCMock', '~> 2.2.2'
end
然后运行pod install
.
首先我们来看看FRPFullSizePhotoViewModel
,因为它最具Objective-C风范(没有太多ReactiveCocoa).
@interface FRPFullSizePhotoViewModel ()
//Private access
@property (nonatomic, assign) NSInteger initialPhotoIndex;
@end
@implementation FRPFullSizePhotoViewModel
- (instancetype)initWithPhotoArray:(NSArray *)photoArray initialPhotoIndex:(NSInteger)initialPhotoIndex {
self = [self initWithModel:photoArray];
if(!self) return nil;
self.initialPhotoIndex = initialPhotoIndex;
return self;
}
- (NSString *)initialPhotoName {
return [self.model[self.initialPhotoIndex] photoName];
}
- (FRPPhotoModel *)photoModelAtIndex:(NSInteger)index {
if(index < 0 || index > self.model.count - 1) {
//Index was out of bounds, return nil
return nil;
}
else {
return self.model[index];
}
}
@end
好了,我们先来测试这个初始化方法,然后在转移到其他两个方法上。
我们想印证初始化我们的视图模型时,它的两个属性model
和initialPhotoIndex
被正确地赋值了。
#import <Specta/Specta.h>
#define EXP_SHORTHAND
#import <Expecta/Expecta.h>
#import <OCMock/OCMock.h>
#import "FRPPhotoModel.h"
#import "FRPFullSizePhotoViewModel.h"
SpecBegin(FRPFullSizePhotoViewModel)
describe(@"FRPFullSizePhotoModel", ^{
it (@"Should assign correct attributes when initialized", ^{
NSArray *model = @[];
NSInteger initialPhotoIndex = 1337;
FRPFullSizePhotoViewModel *viewModel =\
[[FRPFullSizePhotoViewModel alloc] initWithPhotoArray:model
initialPhotoIndex: initialPhotoIndex];
expect(model).to.equal(viewModel.model);
expect(initialPhotoIndex).to.equal(viewModel.initialPhotoIndex);
});
});
SpecEnd
在该代码段顶部,我们导入了一些头文件,包括一个奇怪的预定义EXP_SHORTHAND
,我们把他放在那里以便于可以使用类似expect()
这样的shorthand matchers(速记匹配)的语法。然后我们引入我们的私有接口SpecBegin(...)/SpecEnd
来为我们正在测试的视图模型屏蔽编译警告,最后的部分就是我们的单元测试本身。Specta
的测试规范相当简单,你可以阅读更多的关于这方面的信息,但本书不会深入讲解它的一些细节。总之你的测试始于SpecBegin
并终止于SpecEnd
,测试例程用类似于@"应该。。。",^{ 预测正常的情况应该如何 }
写在中间。
好了,停止模拟器中正在运行的应用,按下cmd+U
快捷键,你就可以运行这段单元测试了。如果一切正常,你就能通过测试。
接下来我们来看看photoModelAtIndex:
方法
- (FRPPhotoModel *)photoModelAtIndex:(NSInteger)index {
if(index < 0 || index > self.model.count - 1 ) {
// Index was out of bounds ,return nil
return nil;
}
else {
return self.model[ index ];
}
}
这里面没有太多的业务逻辑,但是我们看到其他地方都要使用它,所以我们的测试应该是健壮的。
it(@"Should return nil for an out-of-bounds photo index", ^{
NSArray *model = @[[NSobject new]];
NSInteger initialPhotoIndex = 0;
FRPFullSizePhotoViewModel *viewModel = \
[[FRPFullSizePhotoViewModel alloc] initWithPhotoArray:model initialPhotoIndex:initialPhotoIndex];
id subzeroModel = [viewModel photoModelAtIndex:-1];
expect(subzeroModel).to.beNil();
id aboveBoundsModel = [viewModel photoModelAtIndex:model.count];
expect(aboveBoundsModel).to.beNil();
});
it(@"Should return the correct model for photoModelAtIndex:",^{
id photoModel = [NSObject new];
NSArray *model = @[photoModel];
NSInteger initialPhotoIndex = 0;
FRPFullSizePhotoViewModel *viewModel = \
[[FRPFullSizePhotoViewModel alloc] initWithPhotoArray:model initialPhotoIndex:initialPhotoIndex];
id returnModel = [viewModel photoModelAtIndex:0];
expect(returnModel).to.equal(photoModel);
});
太棒了!我们这个新的测试保证了我们的代码具有完全的代码覆盖率。它检测了photoModelAtIndex:
参数的三种可能的情况:少于0、在作用范围内以及越界。
最后,我们来看下initialPhotoName
方法:
- (NSString *)initialPhotoName {
return [self.model[self.initialPhotoIndex] photoName];
}
方法看起来很简单,但实际上这里面包含了更深层级的东西。恰当地重构一些代码并为它写一点不一样的更小的测试代码,来严格地测试这个方法。
- (NSString *)initialPhotoName {
FRPPhotoModel *photoModel = [self initialPhotoModel];
return [photoModel photoName];
}
- (FRPPhotoModel *)initialPhotoModel {
return [self photoModelAtIndex:self.initialPhotoIndex];
}
这更清晰简单了,一个方法确切地只做一件事情,就像一棵树的树皮,层层叠叠相互依存。只要我们一路下来所有的代码都测试,那么最后我们就可以很确切地保证代码的健壮性。
initialPhotoModel
是一个私有方法,所以测试它我们需要在测试文件中申明它。
@interface FRPFullSizePhotoViewModel ()
- (FRPPhotoModel *)initialPhotoModel;
@end
你看到的所有我们的测试代码都非常简单。
it (@"Should return the correct initial photo model", ^{
NSArray *model = @[[NSobject new]];
NSInteger initialPhotoIndex = 0;
FRPFullSizePhotoViewModel *viewModel = \
[[FRPFullSizePhotoViewModel alloc] initWithPhotoArray:model initialPhotoIndex:initialPhotoIndex];
id mockViewModel = [OCMockObject partialMockForObject:viewModel];
[[[mockViewModel expect] andReturn:model[0]] photoModelAtIndex:initialPhotoIndex];
id returnedObject = [mockViewModel initialPhotoModel];
expect(returnedObject).to.equal(model[0]);
[mockViewModel verify];
});
这个测试是用来确认当initialPhotoModel
被调用时,接下来它应该调用photoModelAtIndex:
方法并将initialPhotoIndex
作为参数传入。这个测试是否简单取决于我们测试photoModelAtIndex:
是否充分。
接下来,就让我们一起来看看FRPGalleryViewModel
,这看似非常简单:
- (instancetype)init {
self = [super init];
if(!self) return nil;
RAC(self, model) = [[[FRPPhotoImporter importPhotos] logError] catchTo:[RACSignal empty]];
return self;
}
然而,它可测性不高,需要重构。
我们简单地重构下视图模型。新的实现如下:
@implementation FRPGalleryViewModel
- (instancetype)init {
self = [super init];
if(!self) return nil;
RAC(self, model) = [self importPhotosSignal];
return self;
}
- (RACSignal *)importPhotosSignal {
return [[[FRPPhotoImporter importPhotos] logError] catchTo:[RACSignal empty]];
}
@end
我们把importPhotos
的调用抽出来,以方便测试这个方法是否被调用。我们不会测试FRPPhotoImporter
,关于它的测试(即单例测试)已经超出了本书的范畴。
这部分的测试代码如下:
#import "Specta.h"
#import <OCMock/OCMock.h>
#import "FRPGalleryViewModel.h"
@interface FRPGalleryViewModel ()
- (RACSignal *)importPhotosSignal;
@end
SpecBegin(FRPGalleryViewModel)
describe(@"FRPGalleryViewModel",^{
it(@"should be initialized and call importPhotos", ^{
id mockObject = [OCMockObject mockForClass:[FRPGalleryViewModel class]];
[[[mockObject expect] andReturn:[RACSignal empty]] importPhotosSignal];
mockObject = [mockObject init];
[mockObject verify];
[mockObject stopMocking];
});
});
为了测试一个方法,测试代码也太多了吧! 我知道,我知道~ 这是OCMock没落的原因之一,它竟然需要这么多的模板。但你不能责怪它,因为它要工作在令它不寒而栗的Objective-C平台上!
我们创建了一个FRPGalleryViewModel
的mock版本,告诉它期望importPhotoSignal
被调用。然后才进行对象的初始化。这里使用了一点点技巧,因为我们在mockObject上调用了init方法,但它(init)实际上是一个NSProxy的子类。然后,对OCMock来讲,它足够聪明,它了解这一切,有能力做出正确的选择。只是看起来有点诡异罢了。我们使用[mockObject init]
给mockObject
赋值,也是为了屏蔽编译警告。最后我们验证了所有预期可能被调用的方法。
这个例子中表现出来的测试很困难的情况也说明了另一个问题,你应该避免视图模型的初始化方法产生"副作用"(参见前面章节提到的“函数的副作用”),应该使用didBecomeActiveSignal
来代理。
下面我们来测试FRPPhotoViewModel
.再次突出引起函数副作用和使用didBecomeActiveSignal
的区别。
快速浏览下实现:
@implementation FRPPhotoViewModel
- (intancetype)initWithModel:(FRPPhotoModel *)photoModel {
self = [super initWithModel:photoModel];
if(!self) return nil;
@weakify(self);
[self.didBecomeActiveSignal subscribeNext:^ (id x) {
@strongify(self);
self.loading = YES;
[[FRPPhotoImporter fetchPhotoDetails:self.model]
subscribeError: ^ (NSError *error) {
NSLog(@"Could not fetch photo details: %@",error);
}
completed: ^ {
self.loading = NO;
NSLog(@"Fetched photo details");
}];
}];
RAC(self, photoImage) = [RACObserve(self.model, fullsizedData) map:^id (id value) {
return [UIImage imageWithData:value];
}];
return self;
}
- (NSString *)photoName {
return self.model.photoName;
}
@end
首先我们来测试photoName
方法:
#import <Specta/Specta.h>
#define EXP_SHORTHAND
#import <Expecta/Expecta.h>
#import <OCMock/OCMock.h>
#import "FRPPhotoViewModel.h"
#import "FRPPhotoModel.h"
SpecBegin(FRPPhotoViewModel)
describe (@"FRPPhotoViewModel", ^{
it(@"should return the photo's name property when photoName is invoked", ^{
NSString *name = @"Ash";
id mockPhotoModel = [OCMockObject mockForClass:[FRPPhotoModel class]];
[[[mockPhotoModel stub] andReturn:name] photoName];
FRPPhotoViewModel *viewModel = [[FRPPhotoViewModel alloc] initWithModel:nil];
id mockViewModel = [OCMockObject partialMockForObject:viewModel];
[[[mockViewModel stub] andReturn:mockPhotoModel] model];
id returnName = [mockViewModel photoName];
expect(returnedName).to.equal(name);
[mockPhotoModel stopMocking];
});
});
我们为mock的视图模型的model属性添加了一个mockPhotoModel,它会mocks所有的途径。
现在来看这个复杂的初始化方法,这东西看起来真巨大!近20行纯粹的未经测试的代码。哎呀!让我们来一点点简化这个事情,并逐步加上我们的测试代码。
- (instancetype)initWithModel:(FRPPhotoModel *)photoModel {
self = [super initWithModel:photoModel];
if(!self) return nil;
@weakify(self);
[self.didBecomeActiveSignal subscribeNext:^(id x) {
@strongify(self);
[self downloadPhotoModelDetails];
}];
RAC(self, photoImage) = [RACObserve(self.model, fullsizedData) map:^id (id value) {
return [UIImage imageWithData:value];
}];
return self;
}
- (void)downloadPhotoModelDetails {
self.loading = YES;
[[FRPPhotoImporter fetchPhotoDetails:self.model] subscribeError:^(NSError *error) {
NSLog(@"Could not fetch photo details : %@",error);
} completed:^ {
self.loading = NO;
NSLog(@"Fetched photo details.");
}];
}
我们选择了不直接测试fetchPhotoDetails:
,所以我们把它置于一个实例方法中,以便更容易对它进行测试。这个方法(即fetchPhotoDetails:
)实现的细节在这里对我们不重要。
现在开始写关于它的测试代码吧:
it(@"should download photo model details when it becomes active", ^{
FRPPhotoViewModel *viewModel = [[FRPPhotoViewModel alloc] initWithModel:nil];
id mockViewModel = [OCMockObject partialMockForObject:viewModel];
[[mockViewModel expect] downloadPhotoModelDetails];
[mockViewModel setActive:YES];
[mockViewModel verify];
});
注意看初始化方法中不产生(函数)副作用而是把这种副作用放在订阅didBecomeActiveSignal
的Block块中时,测试视图模型的代码是多么简单!
现在我们需要测试剩下的那些视图模型,他们全部非常简单。我们使用更少的mock,因为很多的业务逻辑仅仅是视图模型的model值到他自己的属性的映射。
it (@"should return the photo's name property when photoName is invoked", ^{
NSString *name = @"Ash";
id mockPhotoModel = [OCMockObject mockForClass:[FRPPhotoModel class]];
[[[mockPhotoModel stub] andReturn:name] photoName];
FRPPhotoViewModel *viewModel = [[FRPPhotoViewModel alloc] initWithModel:nil];
id mockViewModel = [OCMockObject partialMockForObject:viewModel];
[[[mockViewModel stub] andReturn:mockPhotoModel] model];
id returnedName = [mockViewModel photoName];
expect(returnedName).to.equal(name);
[mockPhotoModel stopMocking];
});
it (@"should correctly map image data to UIImage", ^{
UIImage *image = [[UIImage alloc] init];
NSData *imageData = [NSData data];
id mockImage = [OCMockObject mockForClass:[UIImage class]];
[[[mockImage stub] andReturn:image] imageWithData:imageData];
FRPPhotoModel *photoModel = [[FRPPhotoModel alloc] init];
photoModel.fullsizedData = imageData;
__unused FRPPhotoViewModel *viewModel = [[FRPPhotoViewModel alloc] initWithModel:photoModel];
[mockImage verify];
[mockImage stopMocking];
});
it(@"should return the correct photo name", ^{
NSString *name = @"Ash";
FRPPhotoModel *photoModel = [[FRPPhotoModel alloc] init];
photoModel.photoName = name;
FRPPhotoViewModel *viewModel = [[FRPPhotoViewModel alloc] initWithModel:photoModel];
NSString *returnedName = [viewModel photoName];
expect(name).to.equal(returnedName);
});
这就是为视图模型撰写单元测试的全部内容了。
在理想的情况下,单元测试能帮助改进你的代码质量。小巧而高内聚的方法比随意的满是副作用的方法更招人待见。它简单而完美地诠释了函数响应型编程的精髓。
测试MVVM的好处是:我们不用触及UIKit。请记住,写得好的MVVM视图模型的特点是:该视图模型不会与用户交互的接口类有任何交互。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。