测试ViewModels
本书的最后一节，我们谈谈测试，尤其是单元测试。在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
#define EXP_SHORTHAND
#import
#import
#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
#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
#define EXP_SHORTHAND
#import
#import
#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视图模型的特点是：该视图模型不会与用户交互的接口类有任何交互。