随着部门人数的激增，基础研发和基础平台的应运而生。对我们的挑战则是持续集成测试。
　
　　现实情况是需求不可能一成不变，在后期的coding阶段总会由于这样那样的原因而改变，同理设计文档也是。而后期的修改文档的作用是那么的微不足道，那么的突破点貌似只有单元测试文档了。
　
　　假定我们开发和测试资源都充足的情况下，其好处是显而易见的：1. 先写单元测试用例，再写代码，可以有效的抑制开发的代码变动量2. 即使变动，QA也可以第一时间通过单元测试文档获得代码变动情况，调整测试脚本，使得daily test成为可能。否则API测试也只能是在外面隔靴搔痒，而不能真正深入代码深处。
　
　　3. 性能测试发生问题往往是，譬如java数据池中记得建立链接，而忘了关闭链接。c中队列资源使用后的忘记回收。而单元测试则可以提前消灭这些问题。那么是不是投入资源到单元测试更有效呢。
　
　　4. 重要的一点，把单元测试文档纳入svn的管理，进行版本控制。一份代码，一份单元测试文档。
　
　　有句挺有意思的话是这么说：两台电视机，其中一台每个电阻元器件都进行了检验，再组装，整体检验；另外一台，则不管三七二十一，组装为一整体，再进行各项功能测试；那么那台电视机的质量会更让人放心呢，我想答案是很明显的。