iOS尝试用测试驱动的方法开发一个列表模块【二】
2017-08-19 20:48
537 查看
Model的开发经过了文章【一】后,我们先告一段落,现在来想想怎么开发MVC的V和C部分。V的部分我们用现成的UITableView,所以接下来重点关注C的部分。
一开始它没有编译通过
我们创建产品类MyTableViewDataSource,让编译成功,并让这个测试通过
遵循了协议显然还不够,我们需要它确实去实现了我们想要的协议方法,新增几个测试它是否实现了返回行数和Cell的测试用例。
【tc 2.1.2,tc 2.1.3】
显然一开始它们没能通过,因为类只遵循了协议,未实现协议方法,这是一个Red流程。
我们执行Green流程,让这两个测试通过。
甭管我们的产品代码实现是否合理,总之做到能让我们的测试用例通过,就可以了。
现在我们成功执行了Green流程,也发现了测试代码里面有可以重构的地方,所以我们执行一下Refactor流程,把测试用例里面用到的重复代码提取到setUp方法里面。
重构后的测试代码:
重构完成后,我们要确保所有测试用例依然通过。
对UITableViewDelegate的测试方法一样,不再赘述。到此,表格数据源代理类的开发测试先告一段落。
怎么去测试这些类的协作呢,大概分为几个部分:
(1)确认控制器有表格视图、数据源代理类的存在。
(2)确认控制器将数据源代理类成功赋值给表格作为其数据源和代理。
(3)确认表格视图的行数、行高和Cell跟其数据源代理类提供的数据一致。
首先,写测试用例去测试(1)
测试先行,创建针对控制器的测试类MyViewControllerTests,先写会失败的测试用例,执行Red流程。
【tc 2.2.1,测试控制器是否存在一个属性来引用表格控制器】
再执行Green流程,让这个测试通过
很明显,我们只要给控制器一个名叫theTableView的属性,这个测试用例就会通过,不管属性的类型是什么。这不是我们想要的结果,所以我们要追加一个测试用例来规定这个属性必须是UITableView类型的。
【tc 2.2.2】使用到了OC的runtime来获取属性的类型,runtime在测试中是很常用的技术,可以说没有runtime的支持,很多东西都不能或不好去测试。
新加进来的测试用例没通过,这就是我们想要的结果,只有当【tc 2.2.1,tc 2.2.2】都通过时,属性的设置才算是正确的。
现在,我们修改产品代码,让两个测试用例都能通过:
用同样的方法,测试写测试用例,然后为控制器添加另一个theDataSource属性。注意测试属性theDataSource类型的写法跟测试属性theTableView的不太一样。
【tc 2.2.3,测试是否存在theDataSource属性】
【tc 2.2.4,测试theDataSource属性是否是否遵循表格视图的数据源和代理协议】
满足四个测试用例的产品代码:
接下来,我们测试(2)部分的协作,在控制器存在表格视图和数据源代理类的情况下,数据源代理类要作为表格视图的数据源和代理,当控制器的viewDidLoad方法执行之后我们就要确保这一点。
【tc 2.2.5,测试viewDidLoad之后,控制器是否为表格视图赋值了数据源】
【tc 2.2.6,测试viewDidLoad之后,控制器是否为表格视图赋值了代理】
实现控制器的viewDidLoad方法,让以上两个测试用例通过。
最后,我们测试(3)部分的协作,测试表格视图是否接收到了数据源提供的正确数据。
待续。。。。
demo:
https://github.com/zard0/TDDListModuleDemo.git
尝试去开发Controller类
除了需求【5】之外,其他的需求都跟Controller相关,从数据的获取、封装、显示到控制跳转,看起来Controller就会是一个比较多代码的类了。要在Controller里面测试所以上述功能,那么Controller需要暴露很多公共方法和属性,这样Controller就比较难看了,而且也不具备好的封装性。所以,我的策略是将一些相对可以独立的功能单独封装成类,然后分别测试它们,最后测试它们的交互是否正确,通过这种先肢解在合并的方式来测试和开发Controller。哪些功能最适合划分独立的类来处理呢,很容易想到就是UITableView的数据源和代理类,网络请求类,我们先从这两个类下手,其他的,后续有需求在处理。(一)开发表格视图的数据源和代理类
这个类应该实现- (void)testConformUITableViewDelegateProtocol{ MyTableViewDataSource *dataSource = [[MyTableViewDataSource alloc] init]; XCTAssertTrue([dataSource conformsToProtocol:@protocol(UITableViewDataSource)]); }
一开始它没有编译通过
我们创建产品类MyTableViewDataSource,让编译成功,并让这个测试通过
遵循了协议显然还不够,我们需要它确实去实现了我们想要的协议方法,新增几个测试它是否实现了返回行数和Cell的测试用例。
【tc 2.1.2,tc 2.1.3】
- (void)test_ImplMethod_tableView_numberOfRowsInSection{ MyTableViewDataSource *dataSource = [[MyTableViewDataSource alloc] init]; XCTAssertTrue([dataSource respondsToSelector:@selector(tableView: numberOfRowsInSection:)]); } - (void)test_ImplMethod_tableView_cellForRowAtIndexPath{ MyTableViewDataSource *dataSource = [[MyTableViewDataSource alloc] init]; XCTAssertTrue([dataSource respondsToSelector:@selector(tableView: cellForRowAtIndexPath:)]); }
显然一开始它们没能通过,因为类只遵循了协议,未实现协议方法,这是一个Red流程。
我们执行Green流程,让这两个测试通过。
#import "MyTableViewDataSource.h" @implementation MyTableViewDataSource #pragma mark - UITableViewDataSource - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{ return 3; } - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{ return [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"UITableViewCell"]; } @end
甭管我们的产品代码实现是否合理,总之做到能让我们的测试用例通过,就可以了。
现在我们成功执行了Green流程,也发现了测试代码里面有可以重构的地方,所以我们执行一下Refactor流程,把测试用例里面用到的重复代码提取到setUp方法里面。
重构后的测试代码:
#import <XCTest/XCTest.h> #import "MyTableViewDataSource.h" @interface MyTableViewDataSourceTests : XCTestCase @property (nonatomic, strong) MyTableViewDataSource *dataSource; @end @implementation MyTableViewDataSourceTests - (void)setUp { [super setUp]; self.dataSource = [[MyTableViewDataSource alloc] init]; } - (void)tearDown { self.dataSource = nil; [super tearDown]; } - (void)testConformUITableViewDelegateProtocol{ XCTAssertTrue([self.dataSource conformsToProtocol:@protocol(UITableViewDataSource)]); } - (void)test_ImplMethod_tableView_numberOfRowsInSection{ XCTAssertTrue([self.dataSource respondsToSelector:@selector(tableView: numberOfRowsInSection:)]); } - (void)test_ImplMethod_tableView_cellForRowAtIndexPath{ XCTAssertTrue([self.dataSource respondsToSelector:@selector(tableView: cellForRowAtIndexPath:)]); } @end
重构完成后,我们要确保所有测试用例依然通过。
对UITableViewDelegate的测试方法一样,不再赘述。到此,表格数据源代理类的开发测试先告一段落。
(二)开发实现让数据源代理类为表格提供数据
这部分代码是在控制器里面实现的,这部分功能的测试任务是要测试控制器、表格视图和表格数据源代理类这几个类是否协作正确。保证了它们协作正确,这部分的单元测试任务就算完成了,至于表格看不看得到数据,看到的数据是怎样的,其实这不是单元测试的任务了,应该由UI测试去覆盖。怎么去测试这些类的协作呢,大概分为几个部分:
(1)确认控制器有表格视图、数据源代理类的存在。
(2)确认控制器将数据源代理类成功赋值给表格作为其数据源和代理。
(3)确认表格视图的行数、行高和Cell跟其数据源代理类提供的数据一致。
首先,写测试用例去测试(1)
测试先行,创建针对控制器的测试类MyViewControllerTests,先写会失败的测试用例,执行Red流程。
【tc 2.2.1,测试控制器是否存在一个属性来引用表格控制器】
#import <XCTest/XCTest.h> #import <objc/runtime.h> @interface MyViewControllerTests : XCTestCase @end @implementation MyViewControllerTests - (void)setUp { [super setUp]; // Put setup code here. This method is called before the invocation of each test method in the class. } - (void)tearDown { // Put teardown code here. This method is called after the invocation of each test method in the class. [super tearDown]; } /** tc 2.2.1 */ - (void)test_PropertyExist_TheTableView{ objc_property_t theTableViewProperty = class_getProperty([MyViewController class], "theTableView"); XCTAssertTrue(theTableViewProperty != NULL); } @end
再执行Green流程,让这个测试通过
#import <UIKit/UIKit.h> @interface MyViewController : UIViewController @property (nonatomic, strong) NSObject *theTableView; @end
很明显,我们只要给控制器一个名叫theTableView的属性,这个测试用例就会通过,不管属性的类型是什么。这不是我们想要的结果,所以我们要追加一个测试用例来规定这个属性必须是UITableView类型的。
【tc 2.2.2,测试属性theTableView是否是UITableView类型】 /** tc 2.2.2 */ - (void)test_Property_TheTableView_ShouldBeUITableViewType{ NSString *typeName = [self typeForProperty:@"theTableView" inClass:@"MyViewController"]; XCTAssertTrue([typeName isEqualToString:@"UITableView"]); } /** 用法: 1,如果是block类型的属性,这个方法不能识别block的完整sinature,只能告知它是一个block,名字是什么。 返回的字符串样式是:"Block:[属性名]"。 2,如果是id<协议1,协议2>类型,返回字符串样式是:“<[协议1]><[协议2]>”。 3,如果是普通对象属性,返回字符串样式是:“[类名]”。 @param pName <#pName description#> @param cName <#cName description#> @return <#return value description#> */ + (NSString *)typeForProperty:(NSString *)pName inClass:(NSString *)cName{ unsigned int count; Class checkClass = NSClassFromString(cName); objc_property_t* props = class_copyPropertyList(checkClass, &count); for (int i = 0; i < count; i++) { objc_property_t property = props[i]; const char * name = property_getName(property); NSString *propertyName = [NSString stringWithCString:name encoding:NSUTF8StringEncoding]; if (![propertyName isEqualToString:pName]) { continue; } const char * type = property_getAttributes(property); //NSString *attr = [NSString stringWithCString:type encoding:NSUTF8StringEncoding]; NSString * typeString = [NSString stringWithUTF8String:type]; NSArray * attributes = [typeString componentsSeparatedByString:@","]; NSString * typeAttribute = [attributes objectAtIndex:0]; NSString * propertyType = [typeAttribute substringFromIndex:1]; const char * rawPropertyType = [propertyType UTF8String]; if (strcmp(rawPropertyType, @encode(float)) == 0) { //it's a float } else if (strcmp(rawPropertyType, @encode(int)) == 0) { //it's an int } else if (strcmp(rawPropertyType, @encode(id)) == 0) { //it's some sort of object } else { // According to Apples Documentation you can determine the corresponding encoding values } // 针对block属性 if ([attributes containsObject:@"T@?"] &&([attributes containsObject:[NSString stringWithFormat:@"V_%@",propertyName]] || [attributes containsObject:[NSString stringWithFormat:@"V%@",propertyName]])) { return [NSString stringWithFormat:@"Block:%@",propertyName]; } if ([typeAttribute hasPrefix:@"T@"] && [typeAttribute length] > 1) { NSString * typeClassName = [typeAttribute substringWithRange:NSMakeRange(3, [typeAttribute length]-4)]; //turns @"NSDate" into NSDate Class typeClass = NSClassFromString(typeClassName); if (typeClass != nil) { // Here is the corresponding class even for nil values } return typeClassName; } } free(props); return nil; }
【tc 2.2.2】使用到了OC的runtime来获取属性的类型,runtime在测试中是很常用的技术,可以说没有runtime的支持,很多东西都不能或不好去测试。
新加进来的测试用例没通过,这就是我们想要的结果,只有当【tc 2.2.1,tc 2.2.2】都通过时,属性的设置才算是正确的。
现在,我们修改产品代码,让两个测试用例都能通过:
#import <UIKit/UIKit.h> @interface MyViewController : UIViewController @property (nonatomic, strong) UITableView *theTableView; @end
用同样的方法,测试写测试用例,然后为控制器添加另一个theDataSource属性。注意测试属性theDataSource类型的写法跟测试属性theTableView的不太一样。
【tc 2.2.3,测试是否存在theDataSource属性】
【tc 2.2.4,测试theDataSource属性是否是否遵循表格视图的数据源和代理协议】
/** tc 2.2.3 */ - (void)test_PropertyExist_TheDataSource{ objc_property_t theTableViewProperty = class_getProperty([MyViewController class], "theDataSource"); XCTAssertTrue(theTableViewProperty != NULL); } /** tc 2.2.4 */ - (void)test_Property_TheDataSource_ShouldConformUITableViewDataSourceAndUITableViewDelegate{ NSString *typeName = [self typeForProperty:@"theDataSource" inClass:@"MyViewController"]; XCTAssertTrue([typeName isEqualToString:@"<UITableViewDataSource><UITableViewDelegate>"]); }
满足四个测试用例的产品代码:
#import <UIKit/UIKit.h> @interface MyViewController : UIViewController @property (nonatomic, strong) UITableView *theTableView; @property (nonatomic, strong) id<UITableViewDataSource,UITableViewDelegate> theDataSource; @end
接下来,我们测试(2)部分的协作,在控制器存在表格视图和数据源代理类的情况下,数据源代理类要作为表格视图的数据源和代理,当控制器的viewDidLoad方法执行之后我们就要确保这一点。
【tc 2.2.5,测试viewDidLoad之后,控制器是否为表格视图赋值了数据源】
【tc 2.2.6,测试viewDidLoad之后,控制器是否为表格视图赋值了代理】
/** tc 2.2.5 */ - (void)test_viewDidLoad_ConnetDataSourceToTableView{ MyViewController *vc = [[MyViewController alloc] init]; vc.theTableView = [[UITableView alloc] init]; vc.theDataSource = [[MyTableViewDataSource alloc] init]; [vc viewDidLoad]; XCTAssertTrue(vc.theTableView.dataSource == vc.theDataSource); } /** tc 2.2.6 */ - (void)test_viewDidLoad_ConnetDelegateToTableView{ MyViewController *vc = [[MyViewController alloc] init]; vc.theTableView = [[UITableView alloc] init]; vc.theDataSource = [[MyTableViewDataSource alloc] init]; [vc viewDidLoad]; XCTAssertTrue(vc.theTableView.delegate == vc.theDataSource); }
实现控制器的viewDidLoad方法,让以上两个测试用例通过。
- (void)viewDidLoad { [super viewDidLoad]; self.theTableView.dataSource = self.theDataSource; self.theTableView.delegate = self.theDataSource; }
最后,我们测试(3)部分的协作,测试表格视图是否接收到了数据源提供的正确数据。
待续。。。。
demo:
https://github.com/zard0/TDDListModuleDemo.git
相关文章推荐
- iOS尝试用测试驱动的方法开发一个列表模块【五】
- iOS尝试用测试驱动的方法开发一个列表模块【四】
- iOS尝试用测试驱动的方法开发一个列表模块【三】
- iOS尝试用测试驱动的方法开发一个列表模块【一】
- iOS开发那些事--编写OCUnit测试方法-应用测试方法
- iOS开发那些事--编写OCUnit测试方法-应用测试方法
- 测试驱动开发方法可提升整体游戏开发速度
- iOS开发那些事--编写OCUnit测试方法-逻辑测试方法
- 首次尝试测试驱动开发的体会
- 一个hello程序的android内核模块编译方法及在模拟器中进行测试结论
- 测试驱动开发系列之八--测试有合作者的模块
- iOS 测试驱动开发
- iOS开发那些事--编写OCUnit测试方法-逻辑测试方法
- iOS开发那些事--编写OCUnit测试方法-应用测试方法
- iOS 测试驱动开发
- Code maturity level options 代码成熟度选项 [*]Prompt for development and/or incomplete code/drivers 显示尚在开发中或尚未完成的代码与驱动.除非你是测试人员或者开发者,否则请勿选择 我是开发者,所以选[*] Loadable module support 可加载模块支持 [*]Enable loadable module support 内核编译配置选项简介 (2.4.20-8
- ios开发 获取一个视图的子视图的方法
- 首次尝试测试驱动开发的体会
- ios开发 获取一个视图的子视图的方法
- iOS 测试驱动开发