? ? 開始之前說個故事。

? ? 一開始提出代碼包化時團隊是覺得不可思議，這套架構由來已久，而且正運行在超過千萬臺現網設備中，這樣的大改會有多少個坑等著，是個未知數。但考慮到之前提到的困境，如果平臺代碼不能向產品開發團隊交付接近即插即用的代碼包，將會和產品漸行漸遠，失去平臺存在的意義。平臺的開發團隊思考了很久，決定打造質量保護網-單元測試。

? ? ? 我們的產品代碼主要是嵌入式c，測試框架用的是cpputest。結合這次代碼包化調整，我們采用結合ttd方法推動功能代碼的設計實現。

? ? 測試框架如圖所示，每個模塊都有各自的測試用例，內部樁(這里其實我們有的是stub,有的是fake，后面就不區分了，都稱為樁)，向外提供的接口樁，各自可以獨立編譯，運行，顯示結果。

? ? 一套產品，模塊的依賴是比較復雜的，這就決定樁體系不會那么簡單。所以一開始各業務先通過獨立編譯單元測試工程，梳理其依賴，比如收發報文調用，比如系統命令調用，又比如數據庫的調用。業務模塊即使樁的使用者，也是裝的提供者。團隊內匯總后就是樁的需求規劃，就有了開發計劃，下面要做的就是迭代開發。

? ?