標籤： 單元測試 前言 系列
2.3 什麼時候決定進行單元測試（when）
2.4 怎麼進行有效的單元測試（how）
參考資料
前言===
在乙個專案當中，開發者常常要做大量的測試工作，如單元測試，整合測試，回歸測試，壓力測試 .etc。當然，依據專案情況大小和開發者人員水平不同，測試涵蓋的方面自然也是不一樣的。一些測試需要相應的硬體和人力資源，一些需要專門的測試小組，另一些需要提供細緻處理和長時間不間斷執行的環境。
但是今天說的單元測試則不同，它是一種看起來十分廉價和基礎的技術。它由後台程式開發人員建立執行，單機執行，刨除**量以外，對乙個完整的專案開發成本而言，所需的人力物力都是相對較小的。而長久以來的事實也已經證明，單元測試對於**規範性和高效性，以及專案bug的捕獲和解決都有很大的幫助。大多數開發者其實了解這樣的事實，只是因為一些內在和外在的因素（通常是不重視，時間緊和嫌麻煩），往往不願意進行這些測試，或者只在專案快要結束時才想起來，只是已經為時已晚。
所以諸如tdd（測試驅動開發）的專案開發方式，都提倡乙個核心道理：單元測試應該早做，多做，這樣既避免了過度設計，對有效編碼，專案依賴解耦也有好處。而且我們始終要明確，單元測試的第一受益者，永遠是程式設計師。接下來，就讓我們來看看單元測試的一些相關情況，之後再在.net專案中實際執行單元測試吧。
單元測試總覽
===讓我們根據3w+1h原則，先對單元測試有個系統性認識吧
當我們在談論單元測試的時候，我們在談些什麼。——村上春樹按照維基百科上的說法，單元測試（unit testing）又稱為模組測試, 是針對程式模組（軟體設計的最小單位）來進行正確性檢驗的測試工作。程式單元是應用的最小可測試部件。在物件導向程式設計中，最小單元就是方法，包括基類、抽象類、或者派生類（子類）中的方法。按照通俗的理解，乙個單元測試判斷某個特定場條件下某個特定方法的行為，如斐波那契數列演算法，氣泡排序演算法。
單元測試將被測試應用程式細分為乙個個足夠小的基本單元，各個單元間相互獨立，互不影響。開發者能通過單元測試，證明被測試函式的行為確實和開發者期望的一致。為了滿足這個最基本的願望，書寫單元測試前，我們不用考慮太多關於效能上的事情，這是之後優化重構該做的事情。
愛做單元測試的程式設計師，**都不會太差。——古龍上文說到，常常由於專案工期緊張，抑或是程式設計師自身原因的問題，團隊往往在專案接近完成時才進行測試。這其實是非常不提倡的一種做法。就好像我們僱了一批人給我們造房子，從地基開始，造到十幾層了，才用懸垂線來測房子傾斜度一樣不靠譜（假如這個比喻靠譜的話）。到時候高層依賴底層，高層除錯時發現bug，又得讓我們返回底層查詢問題，即便修改之後仍然通過了，但是想必很多朋友也遇到過專案**覆蓋度比較高，一改基礎方法影響一大片的問題吧。
所以當我們從一開始就進行正確的單元測試時，這些問題都是可以解決的。以下羅列出了幾個簡單的作用，以供參考
單元測試最基本的乙個功能，就是快速定位**中的錯誤。從專案一開始，開發者便對所有的單元模組進行測試的話，，除了能盡早發現問題，另一方面對我們專案的持續開發無疑也是提供了極大的保障。當我們設計出乙個良好的單元測試環境，我們勢必會對所有的基本單元進行測試，這時候，單元測試相對於為我們編寫了乙份api文件，我們隨時可以查閱方法相關引數和返回值，以及運**況。單元測試允許程式設計師在之後的開發工作中重構**，並且確保單元依然工作正確。這個過程就是為所有函式和方法編寫單元測試。在連續的單元測試環境中，只要設計出了良好的驗證手段，單元測試可以延續用於準確反映當任何變更發生時可執行程式和**的表現，幫助開發者優化**邏輯和**結構。進行單元測試時，開發者其實站在了乙個觀察除錯的上帝角度。無論是開發先於測試，還是測試先於開發，單元測試都可以幫助我們將模組設計成易測試，易除錯，易重構。在這個過程中，開發者的編碼能力和對業務的理解能力也將得到鍛鍊
早。——魯迅單元測試這東西，就跟戒菸一樣。每個菸民都知道吸菸的壞處（bug），一開始吸菸的時候也會有人提醒你趕快戒菸吧，但是你往往並不在意，等到年限一長（專案開發迭代多次），因為吸菸身體出現的問題越來越嚴重，你可能在這之前做過幾次體檢（整合測試），但是依然於事無補了，等這時候再懷念當初戒菸，乃至不抽菸的好，也是為時已晚。所以單元測試，就該在專案一開始的時候進行測試，在你起了「編寫單元測試太麻煩了，還是算了」的念頭的時候就該開始。博主**水平有限，無止盡的debug和bug提交已經耗費了我很大的精力，所以這才下定決心開始單元測試之旅。
確實不可否認，剛開始就編寫單元測試常常要多花費幾倍的**量，但是隨著專案進行，當你把基礎方法都測試過以後，高層功能需要的**量反而會大大減少。這時候單元測試也在往整合測試遷移，這是乙個順其自然的過程，同時為整合測試的簡化也提供了極大的便利。
單元測試最終呈現出來的效果還是乙個或多個測試方法而已，編寫這些測試方法時，應該注意以下原則
在這之前，我們當然需要區分出應用程式的每個基本單元，這裡有個討巧的方法，就是對專案依賴進行自底而上的遍歷即可，我們並不需要多在意單元測試和整合測試的依賴關係。
——未完待續
單元測試之道有感
單元測試之道有感 這幾天，去看了一下老師發的 單元測之道 這本書，說實話，感觸很大，作者也舉了很多例子，告訴我們單元測試的重要性，單元測試它是服務於人的，它可以使你的工作更輕鬆，減少你在測試上花的時間和精力，那麼問題來了，什麼是單元測試，單元測試是開發者編寫的一小段 用於檢驗被測 的乙個很小的 很明...
單元測試之道讀書筆記 九
總結 一般原則 測試任何可能失敗的地方。測試任何已經失敗的地方。對於新加的 在被證明正確之前，都可能是有問題的。至少編寫和產品 一樣多的測試 針對每次編譯都做區域性測試。簽入 之前做全域性測試。要回答的問題 我如何知道 執行是否正確呢？我要如何對它進行測試？還有那些方面可能會發生錯誤？這個問題是否會...
單元測試之道讀書筆記 七
1.通過使用面向測試的設計方法，更好地分離關注點 通過有意地設計出方便測試的 可以讓 具有更好的結構和可維護性。編寫 的時候要記住這個根本性問題 我要如何對 進行測試呢？如果答案不是顯而易見，編寫的看起來很醜陋或者難以編寫的話，就應該修改一些設計，直到易於測試為止。2.通過定義類不變形更好地產品設計...