标签：
今天给大家着重介绍一下单元测试,很多人可能没有听过单元测试或者是只是听说过,而没有实际的去实践过,没有关系,今天就给大家普及普及这方面的知识,并且带着大家进行实践,切身体验一下单元测试好处.
如果一个移动端的开发人员对单元测试不去重视他，这种开发人员往往表现一种“无知的自信”，总觉得自己写的代码质量很高，直到一次次虫子(Bug)把自己咬的头破血流时,出现重大问题时，才发现原来自己的代码已经到了剪不断理还乱的状态，而每一次修改一个bug，都需要走一遍“墨镜迷宫”
所以我们开发人员有必要对单元测试重视起来,才不会因为程序出了问题而不知所措.
另外还有很多人知道单元测试或者写出了单元测试，但是就是写了一个方法，上面标注了一个[Test]属性而已，甚至很多的人单元测试上面标注的是[IgnoreTest],这些都是不够的,都是比较肤浅的.所以今天带着大家走进单元测试的世界里.
在正式介绍单元测试,大家要明白这样几个概念,如下:
单元测试是开发者编写的一小段代码，用于检验被测代码中的一个很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
执行单元测试，是为了证明某段代码的行为确实和开发者所期望的一致。因此，我们所要测试的是规模很小的、非常独立的功能片段。通过对所有单独部分的行为建立起信心。然后，才能开始测试整个系统。
1. 单元测试使工作完成的更轻松
2. 经过单元测试的代码，质量能够得到保证
3. 单元测试发现的问题很容易定位。
4. 修改代码犯的错，经过单元测试易发现
5. 单元测试可以在早期就发现性能问题
6. 单元测试使你的设计更好
7. 大大减少花在调试上的时间
1. 代码会暗藏很多缺陷,健壮性不强
2. 系统测试发现的缺陷比较难以定位
3. 为了修复缺陷而修改代码，很可能会不小心犯错，但是又不能及时发现这些新错误。
4. 性能问题很难定位，性能优化的时间很难控制。
理论上, 任何代码提交前都应该完整跑一遍所有测试套件. 保持测试代码执行迅捷能够缩短迭代开发周期.
测试套件通常是定期执行的, 执行过程必须完全自动化才有意义. 需要人工检查输出结果的测试不是一个好的单元测试.
对开发环境进行配置, 最好是敲条命令或是点个按钮就能把单个测试用例或测试套件跑起来.
对执行的测试进行覆盖率分析, 得到精确的代码执行覆盖率, 并调查哪些代码未被执行.
每个开发人员在提交前都应该保证新的测试用例执行成功, 当有代码提交时, 现有测试用例也都能跑通.
如果一个定期执行的测试用例执行失败, 整个团队应该放下手上的工作优先解决这个问题.
单元测试即类 (Class) 的测试. 一个 "测试类" 应该只对应于一个 "被测类", 并且 "被测类" 的行为应该被隔离测试. 必须谨慎避免使用单元测试框架来测试整个程序的工作流, 这样的测试既低效又难维护. 工作流测试 (译注: 指跨模块/类的数据流测试) 有它自己的地盘, 但它绝不是单元测试, 必须单独建立和执行.
最简单的测试也远远胜过完全没有测试. 一个简单的 "测试类" 会促使建立 "被测类" 基本的测试骨架, 可以对构建环境, 单元测试环境, 执行环境以及覆盖率分析工具等有效性进行检查, 同时也可以证明 "被测类" 能够被整合和调用.
具体参考准侧请参考:
https://github.com/yangyubo/zh-unit-testing-guidelines
1、写完代码以后：想要验证一下自己写的代码是否有问题。
2、写代码之前：就是写代码之前所有的功能分模块的设计好，测试通过了再写。（我反正是没用过）。
3、修复某个bug后：一般修复完某个bug，为了确保修复是成功的，会写测试。
第一步:我们来创建一个工程
第二步 工程建好了,我们找到系统单元测试Testes文件夹中.m文件看中会到看到几个方法，我们来看下这个几个方法是什么时候调用和他们各自的作用,如图所示.
第三步 我们在viewController.h里面定义一个简单的方法.
第四步 我们在viewController.m里面实现它.
第五步 方法创建完了,我们在测试的文件中导入ViewController.h，同时把申明成一个属性如图所示:
第六步 测试用例实现
1) 正常情况
设置好了,我们command+u快捷方式运行,或者produce–>test运行.
结果显示:
2) 假如返回的结果与我们设定值不等时,结果又会出现什么情况?
第七步 性能测试用例实现
今天就讲到这里,大家对单元测试有没有一个初步的印象了,大家如果要深入的了解单元测试,大家去网上看一些博客去进一步的了解.给大家介绍一本书:
标签：
原文地址：http://blog.csdn.net/super_man_ww/article/details/51360255
