我的一些观点：

　　对于如何进行单元测试，有这么几个观点：

　　一、单元测试的时机很重要

　　无非两种：

　　一是在具体实现代码之前，这就是所谓的测试驱动开发；

　　二是与具体实现代码同步进行，正是大部分人采用的方式。

　　那种事后单元测试，基本是没用的。当然有一种例外：要对没有单元测试的既有代码进行维护和改造，这时候需要为既有代码追加单元测试，但是这也得建立在充分调查理解需求的基础上才能进行。

　　二、单元测试的执行者的角色

　　单元测试应当由具体实现代码的开发者进行，也就是说每个开发人员都应当同时对自己负责具体实现代码和单元测试代码负责。

　　这里也存在同第一条中的例外的情况。

　　三、单元测试应当突出重点

　　应当对那些重点部分重点关照，主要有：

　　1、逻辑复杂的

　　2、容易出错的

　　3、不易理解的，即使是自己过段时间也会遗忘的，看不懂自己的代码，单元测试代码有助于理解代码的功能和需求

　　4、后期需求变更可能性相对比较大的，这样后期需求更变修改代码之后就不用太担心写的代码对不对以及是否破坏既存代码逻辑了

　　四、单元测试也应注重质量，不要写无用的单元测试代码

　　写没有实际用处的单元测试不如不写，正如注释，写没有意义的注释也不如不写。

　　最后要说的是：

　　那种为了单元测试而单元测试的愚蠢行为应当立即停止。

　　那种只是想把单元测试作为一项面子工程的行为更应当停止（官场的种种坏习惯不应该在思想纯洁的程序员当中流行）。

　　那些对单元测试没有深入理解，只是希望今后能冠以“单元测试覆盖率100%”荣誉头衔的团队，应该立即停止这种想法。

　　单元测试不应当过于重视覆盖率，而应该在需要的时候写单元测试。何时写，怎么写，都需要建立在开发者已经对单元测试有深刻理解的基础上。

　　单元测试也是一把双刃剑，要用得好它才能发光发热，产生强大的正能量，请不要把它当作“龙泉宝剑”挂在自家的玄关辟邪。