在基本確定了需要編寫的單元測試，我們還應該問自己：編寫好了這些測試，我們是否可以有把握地告訴自己，如果代碼通過了這些單元測試，我們能認定程序的運行是正確的，符合需求的。如果我們不能非常的確定，就應該看看是否還有遺漏的需要編寫的單元測試或者重新審視我們對軟件需求的理解。通常來說，在開始使用單元測試的時候，更多的單元測試總是沒有錯的。
一旦我們確定了需要被編寫的測試單元，接下來就應該
3. 如何編寫單元測試
在XP下強調單元測試必須由類包的編寫者負責編寫，這個限定對于我們設定的測試目標是必須的。因為只有這樣，測試才能保證對象的運行時態行為符合需求，而僅通過類接口的測試，我們只能確保對象符合靜態約束，因此這就要求我們在測試的過程中，必須開放一定的內部數據結構，或者針對特定的運行行為建立適當的數據記錄，并把這些數據暴露給特定的測試單元。這也就是說我們在編寫單元測試時必須對相應的類包進行修改，這樣的修改也發生在我們以前使用的測試方法中，因此以前的測試標記及其他一些測試技巧仍然可以在Junit測試中改進使用。
由于單元測試的總體目標是負責我們的軟件在運行過程中的正確無誤，因此在我們對一個對象編寫單元測試的時候，我們不但需要保證類的靜態約束符合我們的設計意圖，而且需要保證對象在特定的條件下的運行狀態符合我們的預先設定。還是拿數據庫緩沖池的例子說明，一個緩沖池暴露給其他對象的是一組使用接口，其中包括對池的參數設定、池的初始化、池的銷毀、從這個池里獲得一個數據連接以及釋放連接到池中，對其他對象而言隨著各種條件的觸發而引起池的內部狀態的變化是不需要知道的，這一點也是符合封裝原理的。但是池對象的狀態變化，譬如：緩存的連接數在某些條件下會增長，一個連接在足夠長的運行后需要被徹底釋放從而使池的連接被更新等等，雖然外部對象不需要明確，但是卻是程序運行正確的保證，所以我們的單元測試必須保證這些內部邏輯被正確的運行。
編譯語言的測試和調試是很難對運行的邏輯過程進行跟蹤的，但是我們知道，無論邏輯怎么運行，如果狀態的轉換符合我們的行為設定，那驗證結果顯然是正確的，因此在對一個對象進行單元測試的時候，我們需要對多數的狀態轉換進行分析和對照，從而驗證對象的行為。狀態是通過一系列的狀態數據來描述的，因此編寫單元測試首先分析出狀態的變化過程（狀態轉換圖對這個過程的描述非常清晰），然后根據狀態的定義確定分析的狀態數據，最后是提供這些內部的狀態數據的訪問。在數據庫連接池的例子中，我們對池實現的對象DefaultConnectionProxy的狀態變換進行分析后，我們決定把表征狀態的OracleConnectionCacheImpl對象公開給測試類
文章來源于領測軟件測試網 http://www.kjueaiud.com/
