培訓測試驅動開發有感

由于所在的公司是互聯網行業，很少接觸到軟件工程的概念，所以對于測試驅動這樣的開發模式一直不感冒。由于本次項目中需要用到測試驅動開發來進行，就去聽了測試驅動開發的培訓，感觸頗深

測試驅動開發的一般流程是：

簡單的一點就是新增測試用例->修改代碼->運行測試用例->在修改代碼->運行測試用例->測試用例通過->重構

其中幾個細節點：

對于未實現的方法，不要返回默認值，拋出異常例如UnsupportedOperationException
可測性>封裝性，尤其是內的內部狀態或者內部方法需要測試時，要提供一個get方法獲取內部狀態，要么暴露把變量聲明為public，而方法需要聲明為public
采用測試驅動開發，一定會增加成本。測試驅動開發對于未來的重構有幫助。當產品的生命周期越長，這種開發模式的優勢越明顯，價值也越大。對于一個不斷持續開發的產品來說，測試驅動開發前期投入會非常大，后期維護成本會逐步降低。如果對于生命周期很短的產品，比如一個營銷活動開發的代碼，由于后期很少會對其修改，則測試驅動開發的價值就比較低
測試驅動開發對后期的技術重構會有很大的幫助，但是對于業務重構的價值幫助不大。因為整個業務模式有了很大的變化，相當于重新開發了一套產品。測試用例全部都要重新實現
當單元測試覆蓋率在60%以下的時候，對于整個項目的質量沒有太大的幫助。因為項目主要的流程部分編碼占整個項目編碼的60%，而這一部分會進行重復性的測試。當單元測試覆蓋率達到90%的時候，才能越來越多的發現許多隱藏很深的bug。
分支覆蓋率重要性大于代碼行覆蓋率
先寫代碼，在補寫用例的不是tdd開發模式。