工作中經常看到很多醜陋的**，或者，自己寫的**過一段時間之後自己也覺得很醜陋，促使你不斷的去重構。
那麼，這些醜陋的**是什麼時候編寫的呢？它們到底存在多久了呢？
大多數情況下，這些醜陋**已經存在有些年頭了。即使是你一手支撐的產品或專案，經過幾個版本的迭代之後，1-2年也過去了。
在這些看起來醜陋的**中，很多沒有進行單元測試，可測試性不高，或者根本不可測。或者它們也有可能是 tdd 實踐後的產物，有著不錯的單元測試覆蓋，但依舊是醜陋的**。
但經過漫長的生命週期後，它們存活了下來，並且至今仍發揮著效力。因為，這些醜陋**所實現的業務邏輯是有效和有用的，而業務邏輯所描述的產品還仍然很有生命力。
所以，醜陋**有其存活的理由。只是，這些醜陋的**增加了維護的難度，你需要不斷的償還這些技術債務，甚至一直拖欠著。
在新的專案中，我通常不會直接編寫單元測試**，直到：
直到此時，我才能明確的表達所構建系統的原型，並且通常其已經不再是乙個將被拋棄的原型。
難道這就意味著我有權說我可以不寫單元測試嗎？是的。
因為在此之前，我們一直在不斷的等待各方反饋，以確認我們正在做著正確的事情。而一旦我們已確認所做的事情是正確的，那麼就可以啟動自動化測試了。
幫助理解需求
對設計的快速反饋
提高實現質量
測試成本低
利於重構
文件作用
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...
單元測試（三） 建立多執行緒單元測試
junit本是不支援多執行緒的，乙個單元測試case主程序跑完，其他new出來的執行緒都會gg思密達。此篇mark乙份在junit中執行多執行緒的方法。net.sourceforge.groboutils groboutils core 5test slf4j public class device...