單元測試應該測什么，不應該測什么?

　　這段代碼描述電信營業系統中的繳費開機的過程：

　　User user = User.getUserByServiceId("13309790280");//通過電話號碼找到用戶

　　Account account = user.getAccount();//與用戶關聯的帳戶

　　user.pay(100);//用戶繳費100元

　　//判斷用戶余額+帳戶的信用度-用戶欠費是否大于0

　　if (user.getBalance() + account.getCredit() - user.getDebt() > 0)

　　{

　　Service service = user.getService();//與用戶相關的服務

　　//判斷這個服務是否處于欠費停機狀態

　　if (service.getState() == "欠費停機" || service.getState() == "限制呼出")

　　{

　　…//向交換系統發出開機指令

　　}

　　}

　　這是電信營業系統中最常見的的一個業務。電信系統最基礎的模型應該說是"三戶模型"，三戶模型描述的是客戶(Customer)、帳戶(Account)、用戶(User)以及服務(Service)等等概念的一個關系模型。實際的模型比代碼里的復雜，這里簡化了很多，主要用來舉個例子。

　　要開發一個電信系統，首先要做的就是在系統中實現最基礎的幾個模型，比如三戶模型、聯機指令模型、業務辦理模型、合作伙伴模型……，其中三戶模型處于非常重要的地位。首先要做的是在軟件系統中真實的反映這個模型，絕不可以將其隱含擴散在各個業務過程中。然后就可以在這個基礎上，從一到二、從二到三、從三到萬，實現各個子系統和復雜多變的業務需求。

　　按照TDD的開發思路，我們應該先寫測試代碼，再來寫實際程序，用測試來推動開發的前進。這里先把代碼寫出來，表達一下業務。下面我就說一下，單元測試代碼應該測什么。

　　我們拿User舉個例子，現在我們要寫User類的測試代碼。

　　需要測什么?

　　我們需要測試User類的外在表現。比如我們要測試pay方法，應該這樣：

　　我們建立一個User對象，這個User余額是0，欠費38元。現在繳費100元，繳費完成后，余額應該是62元，欠費應該為0，這是一個Case。

　　我們建立一個User對象，這個User余額是30，欠費0。現在繳費50元，繳費完成后，欠費應該仍然是0，余額應該是80元。這是第二個Case。

　　我們建立一個User對象，這個User的余額是0，欠費150元。現在繳費70元，繳費完成后，欠費應該是80元，余額應該是0。這是第三個Case。

　　我們應該測試的是User類的外在表現，而不應該過問他如何實現。

　　在測試的時候，我們需要一個可以重復的穩定的環境(真實環境往往不行)，有時候無法直接建立 User對象(比如User對象要依賴一個數據集)，有時候真實的環境很難實現一些測試條件(比如邊界值、非正常值)。這時候，我們就可以使用Mock、 Stub這樣的方法，把User建立起來，也把環境建立起來，然后測試User的表現。