很长时间以来，自己想写一篇关于单元测试的文章。但是由于自己在某些方面思考得不是很成熟，再加上前一段时间稍微有点忙，所以这个事情一直这样耽搁下来了。其实，朋友们在开发的时候都知道单元测试是个好东西，但是真正用于实践，并且在开发中一直保持下去的却是少数。虽然单元测试的框架很多，什么CUnit，CxxUnit等存在很多现成的开源代码框架，但是大家使用起来还不是很习惯。至于大家为什么会对单元测试很抵触，我想这主要有几个方面的原因：

　　（1）单元测试会在无形中增加自己的代码开发量；

　　（2）程序员们缺少软件质量的意识，认为保证软件质量是软件测试部门的事情；

　　（3）单元测试的效果无法在短期内有所体现，不如功能开发那样立竿见影；

　　（4）大家习惯了开发、编译、调试、上机测试、修改这样的传统的开发方式；

　　（5）项目至上而下缺少质量控制意识，片面追求开发速度、功能数量、入库行数并过度依赖集成测试。

　　但是，这里我想说的是每一个程序员都必须对自己的代码负责，不管这段代码是你设计的还是你维护的。单元测试是一种很好的验证你代码质量的方法。无论是在设计测试用例、理解代码设计、新功能开发、系统理解方面，单元测试都会对你有所帮助。但是，不可否认，单元测试对个人的要求还是很高的，这需要个人一点点去适应、去改变。

　　a）头文件仿真

　　在单元测试中，为了调用很多的底层函数，通常我们会对某些头文件进行仿真。这个时候，我们引用的函数完全是自己定义和设计的。但是，我们也不能为了现在的测试修改原来的头文件排布。所以，这个时候需要对原有的头文件进行仿真。现在，我们假设原来会引用到一个data_type.h文件，中间有我们需要的函数声明，但是现在不需要了。这时候，我们可以自己定义一个空的data_type.h文件，添几行代码可以了。

#ifndef _DATA_TYPE_H
#define _DATA_TYPE_H

#endif