今天開始，會學習整理測試相關的一些方法、技術。作為一名開發(fā)人員，只有真的懂測試，懂測試手段和策略，才能寫出高質量的代碼。說到底，我就是想寫出更高質量的代碼。
如何做好單元測試？
要做好單元測試，必須弄清楚單元測試的對象是代碼，以及代碼的基本特征和產生錯誤的原因，然后還要掌握單元測試的基本方法和主要技術手段，比如什么是驅動代碼、樁代碼和 Mock 代碼。
第一，代碼的基本特征與產生錯誤的原因
無論什么語言，都會有條件分支、循環(huán)處理和函數調用等最基本的邏輯控制，拋開具體的業(yè)務邏輯，僅看代碼結構，會發(fā)現(xiàn)所有的代碼都是在對數據進行分類處理，每一次條件判斷都是一次分類處理。
任何一個分類遺漏，都會產生缺陷；如果有任何一個分類錯誤，也會產生缺陷；如果分類正確沒有遺漏，但是分類時處理邏輯錯誤，也同樣會產生缺陷。
可見，要做到代碼功能邏輯正確，必須做到分類正確并且完備無遺漏，同時每個分類的處理邏輯必須正確。
作為工程師，具體開發(fā)過程中需要考慮（等價類測試）：
- 如果要實現(xiàn)正確的功能邏輯，會有哪幾種正常的輸入；
- 是否有需要特殊處理的多種邊界輸入；
- 各種潛在非法輸入的可能性以及如何處理。
第二，單元測試用例詳解
單元測試的用例是一個“輸入數據”和“預計輸出”的集合
完整的單元測試“輸入數據”：
- 被測試函數的輸入參數；
- 被測試函數內部需要讀取的全局靜態(tài)變量；
- 被測試函數內部需要讀取的成員變量；
- 函數內部調用子函數獲得的數據；
- 函數內部調用子函數改寫的數據；
- 嵌入式系統(tǒng)中，在中斷調用時改寫的數據；
如果沒有明確的預計輸出，那么測試本身就失去了意義。同樣地，“預計輸出” 絕對不是只有函數返回值這么簡單，還應該包括函數執(zhí)行完成后所改寫的所有數據。 具體來看有以下幾大類：
- 被測試函數的返回值；
- 被測試函數的輸出參數；
- 被測試函數所改寫的成員變量；
- 被測試函數所改寫的全局變量；
- 被測試函數中進行的文件更新；
- 被測試函數中進行的數據庫更新；
- 被測試函數中進行的消息隊列更新；
第三，驅動代碼，樁代碼和 Mock 代碼
- 驅動代碼（Driver）指調用被測函數的代碼
- 樁代碼（Stub）是用來代替真實代碼的臨時代碼。（比如一個方法，直接返回想要的數值）
- Mock 代碼和樁代碼非常類似。
這篇文章是在極客時間上學習的筆記，只是某一節(jié)很小的一部分，如果想更深入的學習，可以去買課程。當然我不是來打廣告的，我只是一名 iOS 開發(fā)。
