一、前言
在大学的时候，写代码随心所欲，想到什么就写什么，只顾实现功能，也不会去验证代码的可行性和稳定性，往往都会在在后续的使用过程中出现各种各样的问题，然后再去捉虫，这样写出来的代码质量差，在后期又耗费大量的时间修复旧代码bug。
参加工作后，接触到了单元测试，在第一个月的考核项目（智能家居控制面板）中，通过请教同事和参考AWTK源码中的单元测试代码，磕磕绊绊得写了一些单元测试，但由于没有设计好项目基础框架，业务逻辑和用户界面没有完全分离，因此只做了文件读写模块和网络通信模块的单元测试。刚好在本周的培训内容中又详细讲了单元测试的FIRST原则，以下记录了单元测试的学习感悟，并使用Google公司开源的C/C++单元测试框架——GTest进进行单元测试。
AWTK是ZLG开源的GUI框架：https://github.com/zlgopen/awtkS
二、什么是单元测试？
单元测试：对软件设计的最小单位进行正确性测试，以检验程序单元是否满足功能、性能、接口、设计规约等要求。
集成测试：将各个程序单元进行有序的、递增的组合进行测试，以检验各个程序单元的配合情况。
系统测试：对集合了应用软件、系统软件、硬件的产品进行测试，以验证产品在实际应用中的功能、性能等特性。
根据传统的开发模型，如瀑布模型，软件开发过程和软件测试活动的关系可以反映为经典的软件测试V模型人，如下图：
其中单元测试中的单元指软件中承担单一职责的单位，通常在程序中体现为一个函数、一个文件、一个类、一个模块等。单元测试都是以自动化方式执行，所以在大量回归测试的场景下更能带来高收益。并且单元测试代码里会提供函数的使用示例，因为单元测试的具体表现形式就是对各种函数以各种不同输入参数组合进行调用。
三、为什么需要单元测试？
在我随心所欲写程序时，经常会遇到一些问题，例如：
· 编译通过，但是要调试好久才能正常运行；
· 好不容易调试好了，但是一测试就会出一堆bug；
· 修复已有的bug，总会产生新的bug；
· bug难以重现，又无法定位；
等等…
以上问题总结一下，就是“你写的代码并不是你想要的结果”，而单元测试则是能保证“你写的代码是你想要的结果”的最有效办法。
单元测试阶段发现的bug更容易定位，并且由于单元测试自动化的特点，更加方便重现bug。在单元测试阶段发现bug，立即修复，不会将各种问题留到最后的系统测试阶段，让代码更可靠、更容易维护，减少后期测试、维护的成本。
总的来讲，单元测试能够提升代码质量，减少程序整体的调试时间。
四、如何做好单元测试？
单元测试需要遵循FIRST原则：
1.F-FAST（快速原则）：单元测试应该是可以快速运行的，在各种测试方法中，单元测试的运行速度是最快的，大型项目的单元测试通常应该在几分钟内运行完毕。
2.I-Independent（独立原则）：单元测试应该是可以独立运行的，单元测试用例互相无强依赖，无对外部资源的强依赖。
3.R-Repeatabl（可重复原则）：单元测试应该可以稳定重复的运行，并且每次运行的结果都是稳定可靠的。
4.S-SelfValidating（自我验证原则）：单元测试应该是用例自动进行验证的，不能依赖人工验证。
5.T-Timely（及时原则）：单元测试必须及时进行编写，更新和维护，以保证用例可以随着业务代码的变化动态的保障质量。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
