### 0、哪些代码需要做单元测试？
理论上只要时间充足，我们除了第三方扩展包，框架源码不需要单元测试外，其余所有业务代码都是需要编写单元测试的。

但往往在实际开发中，给我们留下单元测试的时间并不多，所以就需要将代码按优先级划分了。
1、所有的public 代码都需要完成单元测试。
2、private代码次之。
3、protected代码次之。

### 1、单元测试是程序员还是测试负责？
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。
执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
只要单元测试框架包完善，编写单元测试并不会花费太多时间，单元测试的成本主要是花在后续维护成本中。

### 2、为什么要使用单元测试
单元测试会为我们立的flag做保证。
编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。
有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧，也不需要怕被打脸。

如果有单元测试：
1、单元测试使工作完成的更轻松
2、单元测试使你的设计更好
3、大大减少花在调试上的时间
4、能帮助你更好的理解代码

没有单元测试：
1、任何代码都是在假定其他代码是正确无误的情况下编写的。
2、修改一处代码时无法得知会对其他代码产生怎样的影响。
3、任何一处改动都需要进行功能级别的整体调试。

### 3、什么是Mock，Stub，Spy？

#### A、Spy
Spy的作用在于可以监视一个函数的被调用情况。
函数会被实际调用，Spy相当于给函数加了一层wrapper，可以记录函数被调用了几次，每次的参数是什么，每次返回结果是什么，出了什么异常。

#### B、Stub
Stub的作用是在测试中遇到这样的情形：测试函数f1，f1依赖于函数f2，根据最小化测试粒度的原则，测试f1时不要带入f2的测试，那么我们要确保f2的输出是正确的，所以直接让f2返回正确值的方法就叫stub。
测试时，stub的方法是不会被具体执行的。

#### C、Mock
Mock是对于一个对象的监视，并且需要定义对这个对象的具体期待（verify），也可以理解为模拟期望值，然后验证这些期待是否和测试数据一致。

在一些测试工具中，Mock对象是不会被真正执行的，而Spy是真正执行的。

### 4、单元测试的原则
1、每次只对一个对象进行UT测试。
这样能使你尽快发现问题，而不被各个对象之间的复杂关系所迷惑。

2、给测试方法起个好名字。应该是用形如testXXXYYY()，这样的格式来命名你的测试方法。
前缀test是Junit查找测试方法的依据，XXX应该是你测试的方法名，YYY应该是你测试的状态。
当然如果你只有一种状态需要测试可以直接命名为testXXX()。

3、明确写出出错原因。
在使用assertTrue、assertFalse、assertNotNull、assertNull方法时，应该将可能的错误的描述字符串，以第一个参数传入相应的方法。
这样你可以迅速的找出出错原因。

4、一个UT测试方法只应该测试一种情况。
一个方法中的多次测试，只会混乱你的测试目的。

5、测试任何可能的错误。
你的测试代码不是为了证明你是对的，而是为了证明你没有错。
因此对测试的范围要全面，比如边界值、正常值、错误值；
对代码可能出现的问题要全面预测。

6、让你的测试帮助改善你的代码。
测试代码永远是我们代码的第一个用户，所以不仅让他帮助我们发现Bug，还要帮助我们改善我们的设计，就是有名的测试驱动开发（Test-Driven Development，TDD）。

7、一样的包，不同的位置。
测试的代码和被测试的代码应该放到不同的文件夹中，建议使用这种目录 src/app/代码 src/test/测试代码。
这样可以让两份代码使用一样的包结构，但是放在不同的目录下。

8、关于setup与teardown

a) 不要用TestCase的构造函数初始化Fixture，而要用setUp()和tearDown()方法。
b) 在setUp和tearDown中的代码不应该是与测试方法相关的，而应该是全局相关的。如：针对与测试方法都要用到的数据库链接等等。 
c) 当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。

9、不要在mock object中牵扯到业务逻辑。

10、只对可能产生错误的地方进行测试。
如：一个类中频繁改动的函数。
对于那些仅仅只含有getter/setter的类，如果是由IDE产生的，则可不测；
如果是人工写，那么最好测试一下。

11、尽量不要依赖或假定测试运行的顺序。

12、避免编写有副作用的TestCase，你要确信保持你的测试方法之间是独立的。

13、将测试代码和工作代码放在一起，一边同步编译和更新。

14、确保测试与时间无关，不要依赖使用过期的数据进行测试。
导致在随后的维护过程中很难重现测试。

15、如果你编写的软件面向国际市场，编写测试时要考虑国际化的因素。
不要仅用母语的Locale进行测试。

16、尽可能地利用原生代码所提供地assert/fail方法以及异常处理的方法，可以使代码更为简洁。

17、测试体积要尽可能地小，执行速度快。

### 5、什么使一个好的单元测试？
1、自动：调用测试以及检查通过/失败的结果应该是自动的

2、彻底：覆盖率；虽然bug倾向于聚集在代码中的某些区域，但请确保测试所有关键路径和场景。
如果必须知道未经测试的区域，请使用测试工具。
可重复每次测试都应该产生相同的结果。
测试不应依赖于无法控制的参数。

3、独立：非常重要。
一次测试应该只测试一件事。
只要多个断言都测试一个特性/行为，多个断言就可以了。
当测试失败时，它应该确定问题的位置。
试验不应该互相依赖-孤立。
没有关于测试执行顺序的假设。
使用适当的安装/拆卸，确保每次测试前的“干净板子”。

4、可读性：
这可以被认为是专业人员的一部分，然而，这一点怎么强调也不为过。
一个酸性测试就是找到一个不是你团队成员的人，让他/她在几分钟内找出被测试的人的行为。
测试需要像产品代码一样被维护，因此，即使需要更多的努力，也可以轻松地阅读它。
测试应该是对称的(遵循模式)和简洁(一次测试一个行为)。
使用一致的命名约定(例如TestDox样式)。
避免把“附带的细节”弄得杂乱无章...成为一个极简主义者。

### 6、单元测试的运行快速
单元测试运行很频繁，是辅助开发的，在开发过程中运行，如果运行速度很慢，对效率的影响会很大。
一般要求：
单个测试小于`200ms`
单个测试套件小于`10s`
整个测试小于`10分钟`
即可。

### 7、一致性与原子性
任何时候同样的输入需要同样的结果，例如下面的代码：
`$time = time();`
这样的代码都需要Mock掉，不然时间每次都不同，结果就可能会不一样。
同时，**所有的测试只能有两种结果：成功和失败**
绝对不能部分测试通过。

### 8、单一职责
一个测试只验证一个行为。
**测试行为，不要测试方法**
1、一个方法，多个行为   ----->  多个测试
2、一个行为，多个方法   -----   一个测试
这里的一个行为，多个方法一般指这个方法调用private, protected, getters, setters
多个Assert只有在测试同一个行为时可以接受。

### 9、外部隔离原则
1、单元测试需要快速运行，且每次结果一致，所以需要隔离一切对外部的调用。
2、不使用具体的其它真实类，就是不要new
3、不读数据库
4、不读网络
5、不读外部文件
6、适当时候可以构造一个相同的内部文件来Mock
7、不依赖本地时间
8、不依赖环境变量

### 10、单元测试逻辑
1、单元测试必须容易读和理解的
2、变量名，方法名，类名
3、无条件语句,无Switch
4、办法：分解if到多个测试，所有的输入都是已知的，所有的结果都是一定的（Mock）
5、无循环语句
6、无异常捕捉
7、**测试预知的异常，用ExpectedException方法**

### 11、产品代码
产品代码无测试逻辑，不能有像这样的代码：
`if(global.IsTest){…}`
测试代码和产品代码要分离，
不要在产品代码里有任何只供测试用的代码，
使用依赖注入。

（本篇文章部分转载至网络并加以修改）

已有0条评论

添加新评论☺

如果认为本文对您有所帮助请赞助本站

支付宝扫一扫赞助

已有0条评论

添加新评论☺