如果你想進行重構，首要前提就是要擁有乙個可靠的測試環境。
「編寫優良的測試程式，可以極大的提高我的程式設計速度，即使不進行重構也是如此。」
「class
應該包含他們自己的測試**。」
「每個class
都有乙個測試函式，並用它測試自己這個
class。」
確保所有的測試都完全自動化，讓它們檢查自己的測試結果。
只要寫好一點功能，就立即新增測試。
一整組（a suite of
）測試就是乙個強大的「臭蟲」偵測器，能夠大大縮減查詢「臭蟲」所需要的時間。
「實際上，編寫測試**的最有用時機是在開始程式設計之前。當你需要新增特性的時候，先寫相應的測試**。聽起來離經叛道，其實不然。填寫測試**其實就是問自己：新增這個功能需要做什麼。編寫測試**還能使你把注意力集中於介面而非實現上頭（永遠是件好事）。預先寫好的測試**也為你的工作按上乙個明確的結束標誌：一旦測試**執行正常，工作就可以結束了。」
構建自我測試的**。
頻繁的執行測試，每次編譯請把測試也考慮進去，每天至少執行每個測試一次。
單元測試和功能測試
「每當你接獲臭蟲提報，請先撰寫乙個單元測試來揭發這只臭蟲。」——如何揭發？這裡需要根據報告準確定位。單元測試會對此有幫助嗎？
「觀察class
該做的所有事情，然後針對任何一項功能的任何一種可能失敗的情況，進行測試。」
「測試應該是一種風險驅動（risk driven
）行為，測試的目的是希望找出現在或未來的可能出現的錯誤。」
「測試的訣竅是：測試你最擔心的部分。」
這點和我目前的想法不大相同。我目前的想法是，測試要對程式做100%
的保證，所以，要測試程式可能行為的每一種情況，保證其正確性。按照我的想法，值域的設定和訪問函式也是要測試的。作者的意思是，測試**要用最低的成本，獲取最大的收益。這一點，要我在實際的環境中進行抉擇。
「編寫不是十分完美的測試並實際執行，好過對完美測試的無盡等待。」——我持懷疑態度。
運用測試用例前後執行的函式：teardown
和setup
，保證測試用例之間相互隔離，而非相互影響。
做乙個懶惰的程式設計師——。
考慮可能出錯的邊界條件，把測試火力集中在那兒。
「測試（優先）可以調高程式設計速度」，這一點我要在實踐中驗證一下，如果真是這樣，那我就要嘗試在我們部門推行這種方法。
「當測試達到一定的程度後，測試效益會呈現遞減態勢。」所以，你不要期望通過測試找出所有的bug
，而是要通過測試，找出絕大多數的
bug。
這個地方其實也符合「二八定律」：即20%
的測試可以找出
80%的
bug，其餘的
80%的測試可以找出剩下的
20%的
bug。我們要做的，就是寫這
20%的測試，而非
100%
的測試。
重構 4 構築測試體系
單元測試 高度區域性化，每個測試類都隸屬於單一包。它能夠測試其他包的介面，除此之外它將假設其他包一切正常。功能測試 用來保證軟體能夠正常運作。它們從客戶的角度保障質量，並不關心程式設計師的生產力。每當你收到bug報告，請先編寫單元測試來暴露這個bug。測試風格 觀察類該做的所有事情，然後針對任何一項...
構建測試體系和重構列表
一.自測 的價值 在日常開發中除錯佔據開發的絕大部分時間。確保所有的測試都是自動化完成，讓他們檢測自己的測試結果。在做增量開發時，不要等到開發結束在測試，每新增一點功能馬上測試。寫測試 的好處就是能夠更快的找到bug，節省後期除錯找bug的時間 重構過程中，你可以至執行少數測試項，它主要用來測試當下...
構築高效運維體系 以奇兵奇效制勝
隨著企業資訊化程度越來越高，it資產越來越多，網路管理員和it主管們也會越來越忙，真實情況往往比理想情況複雜得多。在日益複雜的網路環管理環境中，新的裝置 使用者 應用的加入，使得網路中it資源比以前更加分散 複雜。這就要求it運維管理系統能夠針對系統執行環境隨需應變，將以往針對各種基礎資源 監測的各...