1）对架构的反思：架构是否按照分层开发，业务逻辑是否全部在逻辑层实现而非UI实现，这些对单元测试都很重要。虽然现在提供了一些从UI开始的单元测试工具，但推荐方式或说单元测试的重点仍然在逻辑层。

　　2）对自我开发技能的反思：开发不做单元测试而直接做黑盒测试不利于锻炼自己逻辑思维能力，代码静态分析技能。通过进行单元测试，进行分支和覆盖分析，可以加强代码的可测试性，促进代码的重构。

　　3）单元测试是集成测试的基础，如果单元测试都没有做好，那就会把单元，子程序的问题遗留到系统测试的时候才发现。

　　4）不使用单元测试工具或框架也可以自己写相关代码或其它方式进行单元测试，不能单纯理解单元测试就是使用JUnit，NUnit等相关工具。

　　-----------------------------------------------------------------

　　单元测试是检查程序中的最小单位（函数，过程，类，子程序，包）有无错误，一般在编码完成后由开发人员进行。

　　单元测试的目标是检查编码是否符合设计，而不能检查设计是否正确。

　　单元测试的一些方法：

　　静态方法：

　　代码走读：可开发人员间相互走读代码，可设计人员走读开发人员代码，比较随意些。

　　代码走查，审查：召开评审会对编码进行评审，根据编码检查单，和设计相关工件对编码进行评审。这里可以由开发人员自己对代码进行讲解，也可以由他人对编码进行讲解。

　　代码的静态分析对开发人员的技能要求很高，在没有实际运行程序时候就能够清楚的知道程序潜在存在的漏洞和缺陷需要多年的编程的积累和经验的总结。

　　静态测试方法关注的重点是

　　1）编码的规范性

　　2）资源是否释放

　　3）数据结构是否完整和正确

　　4）是否有死代码和死循环

　　5）代码本身是否存在明显的效率和性能问题

　　6）代码本身方法，类和函数的划分是否清晰，易理解

　　7）代码本身是否健壮，是否有完善的异常处理和错误处理

　　通过工具进行单元测试

　　1）静态分析工具（PurifyPlus）

　　2）代码规范审核工具 （FxCorp）

　　3）内存和资源检查工具（PurifyPlus，MemoryChecker）

　　4）测试数据生成工具

　　5）测试框架工具（JUnit NUnit）

　　驱动和打桩（Test Driver & Stub）

　　执行一个单元测试通过三个步骤完成：模拟输入->执行单元->检查验证输出，这就是单元测试的驱动。当我们采用从顶向下执行单元测试的时候，底层执行单元及其子单元可能根本还没有开发完成，这个时候需要模拟一些数据输出来替代实际的单元和子单元。所以打桩一个是对单元的模拟，一个是对单元的替代。