測試的友善開發&敏捷設計

將所有程式分解為類別與方法的方式中，最好的分解方式常常也是最容易測試的方法，另一方面，假設程式彼此十分緊密，類別間有許多交互的方法呼叫，所有類別都有很多參數，這樣程式不只會難以理解，測試程式碼將會變的醜陋、難讀。

一般來說，如果再設計程式的時候體會到”這程式很難測試”，就是個停止考慮這種設計的理由。

 

較少測試程式的特質以及對設計造成的問題

特徵	可測性問題	設計問題
使用全域變數	每次測試都必須重設所有的全域狀態(否則不同測試間會互相影響)	難以理解那些函數產生副作用，各函數無法單獨考慮，需要同時考慮整個程式才能夠正確之道
依賴大量外部元件的程式碼	幾乎無法寫任何測試，因為需要太多的測定過程，測試寫起來一點都不有趣，因此大多數人都不想寫測試	當相依的任何元件出問題，系統就很有可能出問題，很難知道任何變動造成的影響。更難重構類別，系統需要考慮更多失效模式以及回復的方法。
行為不確定的程式	測試很容易無效也不夠可靠，偶爾失敗的測試最後會被直接忽略。	程式更容易產生競爭情況或其他難以重現的Bug，程式更難推論，在正式環境中發生的Bug難以追蹤修正。

高可測試性程式碼的特質及所產生的良好設計

特徵	可測試性問題	設計優點
類別較少的內部狀態	測試會比較容易寫，測試方法需要較少設定	狀態較少的類別比較簡單也比較好懂
類別/函數只做一件事	完整測試需要較少測試案例	較小/較簡單的元件比較模組化，系統通常也較為耦合
類別與較少類別相依:高耦合度	能獨立測試每個類別(比起同時測試多個類別容易得多)	系統能夠平行開發，修改與移除類別都很容易，部會影響系統其他部分
函數有簡單、定義良好的介面	有定義明確的行為可供測試，簡單的介面測試起來也比較容易	程式設計師較容易學習得介面也較可能被重複使用

防止過度測試原則:

1. 為了測試犧牲真正程式碼的可讀性

2. 過度在意100%測試覆蓋率

3. 讓測試影響了產品開發

 

From: The Art of Readable Code

敏捷設計

僵化性(Rigidity) -難以對系統修改。
脆弱性(Fragility)-改動一個地方，程序有許多問題。
牢固性(immobility)-系統糾結難以解開
黏滯性(Viscosity)-錯誤很容易產生，正確卻困難
不必要的複雜性(Needless Complexity)-過度設計
不必要的重複性(Needless Repetition)-程式碼重複
晦澀性(Opactity)-難以閱讀或程式碼表達不順