单元测试

今天开始，会学习整理测试相关的一些方法、技术。作为一名开发人员，只有真的懂测试，懂测试手段和策略，才能写出高质量的代码。说到底，我就是想写出更高质量的代码。

如何做好单元测试？

要做好单元测试，必须弄清楚单元测试的对象是代码，以及代码的基本特征和产生错误的原因，然后还要掌握单元测试的基本方法和主要技术手段，比如什么是驱动代码、桩代码和 Mock 代码。

第一，代码的基本特征与产生错误的原因

无论什么语言，都会有条件分支、循环处理和函数调用等最基本的逻辑控制，抛开具体的业务逻辑，仅看代码结构，会发现所有的代码都是在对数据进行分类处理，每一次条件判断都是一次分类处理。

任何一个分类遗漏，都会产生缺陷；如果有任何一个分类错误，也会产生缺陷；如果分类正确没有遗漏，但是分类时处理逻辑错误，也同样会产生缺陷。

可见，要做到代码功能逻辑正确，必须做到分类正确并且完备无遗漏，同时每个分类的处理逻辑必须正确。

作为工程师，具体开发过程中需要考虑（等价类测试）：

• 如果要实现正确的功能逻辑，会有哪几种正常的输入；
• 是否有需要特殊处理的多种边界输入；
• 各种潜在非法输入的可能性以及如何处理。

第二，单元测试用例详解

单元测试的用例是一个“输入数据”和“预计输出”的集合

完整的单元测试“输入数据”：

• 被测试函数的输入参数；
• 被测试函数内部需要读取的全局静态变量；
• 被测试函数内部需要读取的成员变量；
• 函数内部调用子函数获得的数据；
• 函数内部调用子函数改写的数据；
• 嵌入式系统中，在中断调用时改写的数据；

如果没有明确的预计输出，那么测试本身就失去了意义。同样地，“预计输出” 绝对不是只有函数返回值这么简单，还应该包括函数执行完成后所改写的所有数据。 具体来看有以下几大类：

• 被测试函数的返回值；
• 被测试函数的输出参数；
• 被测试函数所改写的成员变量；
• 被测试函数所改写的全局变量；
• 被测试函数中进行的文件更新；
• 被测试函数中进行的数据库更新；
• 被测试函数中进行的消息队列更新；

第三，驱动代码，桩代码和 Mock 代码

• 驱动代码（Driver）指调用被测函数的代码
• 桩代码（Stub）是用来代替真实代码的临时代码。（比如一个方法，直接返回想要的数值）
• Mock 代码和桩代码非常类似。

这篇文章是在极客时间上学习的笔记，只是某一节很小的一部分，如果想更深入的学习，可以去买课程。当然我不是来打广告的，我只是一名 iOS 开发。