一、前言
在之前的單元測試的過程中，由于對單元測試的概念沒有足夠的理解，所以舍本逐末，造成了把單元測試和集成測試混淆的錯誤做法，所以我周末在家閱讀了相關的書籍和文檔，才對單元測試測試初步的認識，以下我講解的將會是iOS和Android的共同部分，由于我不懂Java，所以就不細節闡述了。
二、概念
單元測試是指對軟件系統中最小可測試單元進行的檢查和驗證。所謂的單元，需要根據實際情況去判斷，一般指的是功能不可再分的模塊或者函數。（對類和方法的測試）
集成測試是單元測試的邏輯擴展，最簡單的形式是把兩個已經測試過的單元測試組合成一個組件，并測試他們之間的接口。在軟件開發中，集成測試可以簡單的分為API接口測試和功能集成測試。API接口測試是指程序以網絡請求的方式使用到了后臺服務的功能，測試時需要驗證網絡的請求以及相應是否符合預期。功能集成測試其實就是功能的測試。
三、框架
單元測試比較流行的框架有兩種：測試驅動開發（TDD，Test Driven Development）和行為驅動開發（BDD，Behavior Driven Development）。
測試驅動開發是一種測試先于編寫代碼的思想，用于指導軟件開發。舉個例子來說明，TDD就像是在砌墻之前的一條輔助的拉線，根據這條輔助的拉線來判斷墻是否砌的平穩，如果墻砌好了之后再來測量是否平穩，那就免不了的需要各種重修了。所以這種框架現在不適合我們的項目。
行為驅動開發是一種敏捷軟件開發的技術，是TDD的一種延伸，通過Given-When-Then三個流程化的條件來幫助開發確定應該測試什么。
這種方式有什么優勢呢？舉個例子，以前的模式可能是市場業務人員發現一個問題，然后轉述給產品經理或者測試，然后再轉述給開發人員，開發人員根據這個特征來還原這個問題，寫成一個測試用例，但是在轉述中間過程中很可能就丟失了關鍵的部分，所以是不嚴謹的。
但是BDD就像是講故事一樣，最一開始這個需求的提出者根據Given-When-Then的流程化描述清楚這個問題，把用戶或者客戶真正的通過Feature文件聯系在一起了，其溝通是順暢的，QA，PM，開發，測試，客戶，用戶可以通過這一媒介，進行高效無障礙的溝通。
根據我們現在開發的現狀，肯定是選擇BDD框架。
四、方法
4.1、測試方法
我們可以根據Given-When-Then模式來組織我們的測試，把測試拆分為三個部分。
given：通過創建模型對象或者將被測試的系統設置到指定的狀態，來設定測試環境。
when：這部分包含了我們要測試的代碼，一般情況下這里只有一個方法調用。
then：我們需要檢查我們行為的結果。
4.2、可重用代碼
隨時單元測試的用例的增多，測試中重復的代碼也會也來越多，我們需要把代碼片段整理出來，加入到一個公共類中，為所有的測試用例服務。
4.3、Mock
Mock測試：就是在測試過程中，對于某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來創建以便測試的測試方法。
我們不應該過度mock，在適當的情況下，可以使用真實對象來保證正確性。
但是在Mock的時候我們無法保證這個Mock的正確性，所以我們在Mock結束之后，應該去驗證這個Mock的正確性。
4.4、驗證
被單元測試的對象或者系統，我們簡稱為SUT（System Under Test，被測試系統），SUT大致可以分為三種：
- 有明確的返回值，通過返回值判斷是否符合預期，這種方法被稱為返回值驗證法。
- 沒有返回值，但是這個方法會改變其對象內部的一些屬性或者狀態，這種方法被稱為狀態驗證法。
- 依賴于外部的一個類或者方法，它會調用外部的一個 方法，被稱為行為驗證法。（比如代理回調函數）
五、結語
測試中需要注意的點：
- 不需要測試私有方法。
- 不需要測試構造函數，因為構造函數不應該包含行為，所以沒有值得測試的東西。
- 不要Stub私有方法和外部庫。
備注
BDD中也有很多種的選擇方案：
- XCTest + OCMock（iOS）、JUnit + Mocktio（Android）
- Kiwi（自帶mock）
