单元测试 - 草稿

    开始之前说个故事。

    一开始提出代码包化时团队是觉得不可思议，这套架构由来已久，而且正运行在超过千万台现网设备中，这样的大改会有多少个坑等着，是个未知数。但考虑到之前提到的困境，如果平台代码不能向产品开发团队交付接近即插即用的代码包，将会和产品渐行渐远，失去平台存在的意义。平台的开发团队思考了很久，决定打造质量保护网-单元测试。

      我们的产品代码主要是嵌入式c，测试框架用的是cpputest。结合这次代码包化调整，我们采用结合ttd方法推动功能代码的设计实现。

    测试框架如图所示，每个模块都有各自的测试用例，内部桩(这里其实我们有的是stub,有的是fake，后面就不区分了，都称为桩)，向外提供的接口桩，各自可以独立编译，运行，显示结果。

    一套产品，模块的依赖是比较复杂的，这就决定桩体系不会那么简单。所以一开始各业务先通过独立编译单元测试工程，梳理其依赖，比如收发报文调用，比如系统命令调用，又比如数据库的调用。业务模块即使桩的使用者，也是装的提供者。团队内汇总后就是桩的需求规划，就有了开发计划，下面要做的就是迭代开发。