一、单元测试
单元测试是最基本的测试，一般来说，它是由设计开发人员来做的，或者直白一点是由程序员展开的。它属于白盒测试。它并没有什么官方权威的定义，通常认为是对软件中最小单元及单元之间的相关逻辑进行的测试。这个最小单元就比较难于定义，到底是一个类，一个函数，一组函数，一个功能模块还是什么？所以就需要开发人员有较高的抽象能力。这也是TDD（测试驱动开发）开发的一个缘由，这里不展开什么是TDD。
单元测试的特点在于，它的输入参数和输出结果是稳定、可控的。它可以明确基础单元的基础逻辑和功能的鲁棒性，提高软件质量，降低后期测试的压力并尽早的发现解决Bug。
而随着技术的进步，又出现了现代单元测试，其一方面模糊最小单元的粒度，另一方面在单元测试时引入框架进行黑盒测试，从而满足全自动运行的最小单元级别的软件测试。
其实无论是哪种，都是为了把基础打牢，这才是根本。“基础不牢，地动山摇”。
单元测试有几个基本的要求：
1、异常测试尽量覆盖全面。
2、增加断言控制，并设置相关显示结果提示。
3、提高测试代码设计能力。
4、尽量降低软件耦合，提高单元测试数量。
5、测试代码尽可能重用。
6、争取引入TDD。
二、GTest的基本应用
单元测试的框架(当然，从更宏观的角度看，还可能含有一些自动化的工具相关框架，这里仅指单元测试)有很多，比较常见的有xUnit系列，如JUnit,JMeter等。在C/C++中，常用的有Boost Test，CppUnit，TestNgpp和谷歌的gtest框架。这次主要介绍Gtest，其它的有兴趣可以自己查阅相关的资料，都比较好用，不用有什么担心。
看一个gtest的基本应用：
先看一下源码Demo：
int Add(const int & e)
{
if (e < 0)
{
return -1;
}
vec.emplace_back(e);
return 0;
}
再看一下测试代码：
TEST(AddTest, testNP)
{
EXPECT_EQ(-1, Add(-100));
EXPECT_EQ(0, Add(100));
}
从软件工程和技术架构师的角度来说，单元一定要有，必须要有，肯定要有。但实际情况，得看上峰的眼色，具体就不展开了。
三、总结
单元测试的优势在于可回归性和随时可以进行，相比其它测试，简单明了。同时，编写清晰完整的单元测试本身就是一份软件代码的开发和说明文档，由此看来，单元测试的重要性非同一般。特别是文章开头提到的TDD，更是一种思想上的升华。可惜的是，在国内，能够认真真正贯彻并编写单元测试的公司基本上是没有。什么原因，大家都清楚，没有讨论的必要。尽管如此，还是建议大家有时间的情况下，尽量编写一个单元测试，这样，就会有一个从应用者来看待自己代码的一个角度来发现自己代码问题的算途径，至于能不能发现，尽人事，安天命。
后面的文章会继续展开对gtest应用的介绍！
