由于受到極限編程的影響，在最近的幾年時間里單元測試逐漸成為我軟件開發過程中一個不可或缺的重要組成部分。極限編程要求我們對我們所完成的每一項功能都要進行單元測試并且要很好的管理這些測試，我們不應該在所有的單元測試通過之前去集成任何新的功能。這種做法的好處就是可以讓開發人員對自己所寫的代碼充滿信心（而不是盲目的毫無根據的自負）。
最開始我認為既然已經有了單元測試了，就沒有必要再去花時間在功能測試上了，可我現在知道這是一個錯誤的想法：單元測試和功能測試是有很大的不同的。我花了很長的時間才了解到單元測試和功能測試的差異所在，我也知道了怎樣更好的運用單元測試和功能測試來完善我們的軟件開發流程。
這篇文章探究了單元測試和功能測試的不同點以及我們可以怎樣運用這兩種測試來支持我們的軟件開發。
測試和軟件開發過程
作為一個開發人員來講，測試是相當重要的，我們必須要堅持在整個軟件開發流程中測試我們的代碼，而不僅僅把測試作為軟件開發的一個特殊階段的產物：測試絕對不應該成為你在軟件提交前一天才開始的一個例行公事。你怎么才能知道我們的軟件已經可以發布了？你怎么知道我修正了這個小bug的時候沒有引發一個更嚴重的系統bug？你怎么知道當前的系統是否可以擴展一些現在沒有想到功能呢？測試！單元測試和功能測試必須成為我們在軟件開發流程中的一個有機組成部分。
單元測試應該成為你寫代碼的一個核心部分，尤其是在項目時間比較緊張但是我們仍然要保證質量的時候。單元測試十分重要，你甚至應該在你的代碼寫出來之前就應該完成單元測試。
單元測試：
-》有助于盡可能地重現最有效的設計
-》有助于提供一個最佳的文件組織結構
-》有助于確定一個類是否完成
-》讓開發人員對自己的代碼充滿信心
-》是快速重構的基礎
單元測試有助于形成系統化的并可以不斷改進的設計文檔，這些文檔在軟件開發的過程中有著極其重要的意義。大多時候將用例文檔化形成一個類要比僅僅羅列一大堆編碼的實際用例好，看看單元測試：它提供一系列有規律的輸入或數據，用一系列的實際用例來告訴我們所寫的類做了些什么。這樣的話這個設計文檔就總是最新的，因為我們必須通過單元測試。
你應該在寫代碼之前寫單元測試，這樣做的好處就是為自己提供了一個可以測試的設計方案，這就可以幫助你想的更加完善，這樣會使設計變得簡單。你不必擔心將來會怎樣，也不必花時間去實現一些不必要的功能。首先寫單元測試還有助于幫你了解代碼在什么時候完成：當所有的測試都通過之后，我們的任務也就完成了。
最后，單元測試讓你對自己代碼有高度的自信，這有助于我們做出更加好的產品。當你修改了自己的代碼之后，我們來運行我們的測試，如果有問題的話我們可以迅速找出來我們的修改產生了在什么地方哪些破壞。
功能測試甚至比單元測試更加重要，因為它是用來檢測我們的系統是否達到可以發布的要求。功能測試是用來確定我們的系統是否是一個可用的系統。
功能測試：
-》確定是否實現用戶需求的一個有效方法
-》讓用戶和開發人員了解到我們的系統已經實現了這些用戶需求
傳統的開發過程是從實際使用中確定是否實現用戶需求的，通常人們需要花費大力氣才可以搞清楚這些實際用例并設法概括它們，當他們完成了這些工作之后他們手中無非多了一張紙而已，而功能測試就像是自己確定實際用例一樣。極限編程闡述了這些觀念，極限編程需要提前定義這些功能（這一過程需要項目組和用戶共同完成），而功能測試就是它的產物，如果沒有功能測試的話，我們不可能完成的很漂亮。
功能測試可以檢查出單元測試遺留下的一些軟件缺陷，讓開發人員對自己的代碼更加有信心，因為單元測試仍然會遺留下很多bug，它可能會覆蓋到代碼的各個部分但是卻不能覆蓋到系統的各個部分。功能測試可以揭露一些單元測試沒有涉及的問題。當然一個自動化的可持續運行的功能測試不可能找出系統中的所有問題，但它可以找出更多的單元測試找不到的bug。