如今TDD很火，我公司小，一般写代码不写测试用例的，一般就是随便测试下函数的输入输出，没用工具或框架来测试，非常简单，一点也不正规化。
在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中， 要进行测试的基本单元是类。
单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。 旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。
在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。
在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。
很多研究成果表明，无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，因此从经济角度来看， 应该尽可能早的查找和修改Bug。在修改费用变的过高之前，单元测试是一个在早期抓住Bug的机会。
推荐几款测试框架：
cpputest ，gooletest（这个也推荐），goolemock，cppunit（听说这款非常优秀，但是没有试过）
这是微软提供的测试框架（至少是VS2013）：
https://msdn.microsoft.com/en-us/library/hh598953(v=vs.120).aspx
另外，vczh大神在知乎上建议软件开发中，用源文件的方式来划分功能，别用函数粒度的方式来划分软件功能。比如压缩这个功能compress.h compress.cpp。这样或许单元测试也更方便。按Qt的套路是一个C++类算一个功能，所以一个.h头文件和.cpp文件分别是这个单一C++类的声明和实现。知乎上的很多牛人也赞同Qt项目是C++运用非常好的项目。
references：
http://www.cnblogs.com/wang_yb/p/3999701.html
http://www.ibm.com/developerworks/cn/linux/l-cn-cppunittest/
http://www.cnblogs.com/cxjchen/archive/2013/05/16/3081118.html
http://tech.ccidnet.com/art/3737/20060907/894191_1.html
http://www.cnblogs.com/SelaSelah/archive/2012/04/11/2442525.html