測試驅動開發之基礎---單元測試

    學習測試驅動開發以前，應當正確理解一下單元測試的概念，學習單元測試以後能夠清楚的知道所謂的單元爲單一職責的一個方法即一個方法只作一件事情，這也符合面向對象的單一職責的原則。所以單元測試的概念能夠籠統的理解爲：針對一個工做單元設計的測試。

     單元測試有各類不一樣的編寫方式，但全部單元測試有些共同的特徵：

    1.代碼的隔離性

    2.與團隊其餘人員代碼的隔離性

    3.有針對性

    4.可預測性

    5.可重複的

    知道了什麼是單元測試，那麼咱們就應該很清楚的知道若是進行一個單元測試，測試的範圍應該不超越要測試的內容邊界，若是一旦超過了測試邊界，那麼就值得咱們去深思一下，咱們作的是否是單元測試了。

    什麼樣的測試不是單元測試呢?咱們在一個系統中寫出一個個單元，這些單元不免與系統的其餘部分有交叉性如數據庫、其餘系統或第三方產品系統，從而形成了被測代碼與其餘部分存在邊界，所以測試時，若是產生問題有可能穿越幾層代碼，從而使測試失去了針對性，違背了單元測試背後的內容：只測試這個方法中的內容。跨邊界時還會產生另一個問題，特別是邊界是一個共享資源時如數據庫，與團隊中的其餘成員共享資源時，可能會污染他們的測試結果，例如，當本身運行測試寫入值再讀取時，其餘成員也在處理同一代碼，有這樣就形成了測試的相互干擾，形成了測試環境的不穩定性。

    並非說那些跨過測試類或方法的測試就沒有意義了，一組代碼若是不能集成到更大的系統中，其價值是有限的。所以集成測試很是的重要，它是衡量整個系統的健康程度，因此集成測試也應該在開發過程當中建立。常見的一種作法是 按特徵劃分工做單元並經過單元測試，而後集成測試，確保工做單元可使用其餘部分單元或被其餘部分正常使用，所以咱們應該-早集成，常集成。

    以上不知理解是否正確歡迎各位大俠拍磚。