iOS单元测试怎么写 ？

　　什么是单元测试 ?
　　针对程序模块（软件设计的小单位）来进行正确性检验的测试工作。程序单元是应用的小可测试部件。对于面向对象编程，小单元是方法
　　iOS 集成了自己的测试框架 OCUnit 和 UITests
　　为什么单元测试 ?
　　执行单元测试，是为了证明这段代码的行为和我们期望的一致，比如测试一些功能是否正常，接口是否能正常，特别在一些大的项目，以防止程序被误改或引起新的问题 。
　　单元测试还具有一下几个好处:
　　· 协助程序员尽快找到BUG的具体位置
　　· 让程序员对自己的程序更有自信
　　· 能够让程序员在提交项目之前将代码变的更加健壮
　　· 能够协助程序员更好的进行开发
　　· 能够向其他程序员展现你的程序该如何调用
　　· 能够让项目主管更了解系统的当前状况
　　如对其意义仍有疑惑请看这篇文章
　　单元测试 怎么写 ?
　　我在刚写单元测试，也看了网上有很多文章，但是依然无从下手。本文总结了几点，并摘录了一些例子。
　　什么该测试
　　项目中的公共类中的公开方法，将公共组件加入单元测试可以大大加强底层操作的正确性和健壮性。
　　网络数据层方法的测试，数据接口一般不会太多，这里的测试可以保证接口的正常。
　　业务逻辑层测试，这样可以让业务逻辑保持正确，产品发布后可以直接通过业务逻辑的单元测试来找到BUG。
　　修复bug时测试， 如用户反映有个bug ，可以先写个测试复现bug，接着找到问题修复bug ，测试验证，后要保留测试，
　　更易于测试的代码
　　很多时候，项目中难免发生多个类之间的交互处理， 耦合度高，而这种操作非常的不好调试。
　　单元测试的原则之一在于我们用来测试的代码要求功能很单一，这其实与良好的代码设计的思想是非常相符的。
　　一方面来说，良好的代码结构设计可以让我们的测试用例的构建更加快速简单；反过来单元测试逼着我们去想办法减少类之间的耦合以此来减少甚至排除测试的干扰。无论如何，如果你想成为更好的开发者，单元测试是我们快速提升代码认知的重要手段之一。
　　关注覆盖率
　　单元测试写的是否合理或者是否达到了要求的一个的标准是整个测试的代码覆盖率。代码覆盖率其实是测试代码所运行到的实际程序路径的覆盖率。在实际程序中可能会有很多的循环、判断等分支路径。一个好的单元测试应该能够将所有可能的路径都将走到，这样可以保证大多数情况都测试过了。
　　边界条件数据，比如值类型数据的大值、小值、DBNull，或者是方法中所使用的条件边界，例如a>100那么100变成了这个数据的边界。而且在测试的时候还必须把超出边界的数据作为测试条件进行测试。
　　空数据，一般空数据对应于引用类型的数据，也是Null值。
　　格式不正确数据，对于引用类型的数据或者结构对象，类型虽然正确但是其内部的数据结构不正确的数据。例如一个数据库实体对象，数据库中要求其某个属性必须为非空，但是这时我们可以属于一个空。这样这个对象属于一个不正确数据库。
　　在编写单元测试代码的时候先了解到被测试方法可能会使用的外部数据，然后将这些外部数据一次设置为上面规定的这几种情况，然后再执行方法。这样基本可以达到外部数据所有情况都能够正确测试到了。
　　摘录的一些例子
　　例1
　　在逻辑测试的某个操作步骤前后，应该有对应的数据发生了改变，这样才能够方便我们进行测试：
@interface LXDTestsModel : NSObject
@property (nonatomic， readonly， copy) NSString * name;
@property (nonatomic， readonly， strong) NSNumber * age;
@property (nonatomic， readonly， assign) NSUInteger flags;
+ (instancetype)modelWithName: (NSString *)name age: (NSNumber *)age flags: (NSUInteger)flags;
- (instancetype)initWithDictionary: (NSDictionary *)dict;
- (NSDictionary *)modelToDictionary;
@end