单元测试框架
公司的没有单元测试的要求，也没有单元测试的相关规范。基本都是随机测试，随便写点测试代码，也没有维护过测试代码，提交版本测试代码也就扔了。
开始认为单元测试费力不讨好，认为小的功能不需要这玩意，随着做开发时间变长，才觉得这玩意很有必要。写之前先总结下我理解的单元测试。
一、必要性
1）开发人员能够对代码设思考，写出更易读，结构性更好代码
不是所有的代码都可以很优雅进行单元测试的。单元测试要求代码有较好的内聚和不同功能的解耦，要求对类设计更加面向对象，要求函数功能清晰，命名参数设计合理。所以在开发人员写代码前（或者写代码后）对代码进行更高要求的设计（或重构）。从而简洁的提高了代码的质量与可读性。
2）维护人员能够更容易理解代码
单元测试也是对如何使用代码的一种说明，换句话说，别人在使用的时候如果不知道代码是“解决什么问题”，那么可以先读读单元测试。
3）能够回归测试
不用每次改动一行代码就忧心忡忡想着代码会挂掉么，跑一遍单元测试，就踏实很多。
4）验证代码逻辑
这也是单元测试的目的，也是曾经我理解的单元测试。
上面是目前体会到的必要性，其实还有别的作用，从设计、开发进度检查、维护等各个角度单元测试都有其作用。引用一句别人文章的话“单元测试的普遍接受，已经成为过去5~7年里软件开发领域里最大的进步之一！”。下面这篇文章有更深入的解释。 《我同情那些不写单元测试的傻瓜》 http://blog.csdn.net/happydeer/article/details/8424453
二、矛盾
1）在前还是在后 直接引用别人文章内容吧“当我修改设计的时候，就会有一大堆测试通不过。这意味着，我要么少写一点测试，要么尽量少做大的设计修改。但两者都是不理想的。 为了避免这个问题，我只能退而求其次——测试晚一点再介入——但这又跟新潮的“测试驱动开发”模式背道而驰。编写单元测试是必要的，积极地重构代码也是必要的。你是如何来平衡的呢？” 这也是个问题，我目前还是开发完在写单元测试，因为工期有限，领导问题开发多少功能了，不能说还没开始吧。
2）度的把握（100%覆盖率？） 单元测试有个代码覆盖率的问题，如果要求路径覆盖率100%，那么研发周期会大大加长，而且没有必要。如果没有覆盖率的要求，研发人员自觉性不高或者时间紧迫，那么可能单元测试就成为形式。
目前我司完全靠自觉了。如果没有单元测试，那么可能以后质量问题会很多，bug增多，修改维护时间增多，没准加班时间也会变长。出来混迟早要还的，每个研发如果认识到这，写单元测试是为了自己，也许覆盖率不那么重要了。
三、框架与规则
所谓框架就像JUnit，CppUnit，GTest等等，方便单元测试。框架使用都不复杂，甚至可以自己实现。c++的测试框架待选的有cppunit和gtest，但gtest模板语法比较高级vc6编译不动，只有选择cppunit，其实都一样，一个工具而已。
规则就涉及到测试工程、类、函数命名规则等等。应该属于代码规范一部分。定义规则如下:
1）工程与待测试的工程一般一一对应，包括目录结构等，名字一般为xxxTest
2) 类名一般叫做xxxTest
3) 测试方法为Testxxx，一般测试public方法
4) 如果需要测试protect或者private方法，最好在待测试的类内部先声明友元类friend class xxxTest
5) 每个工程包括main方法，可以生成exe运行测试