React總結篇之八_單元測試
阿新 • • 發佈：2018-11-23
一、單元測試的原則
從不同的角度，可以將測試劃分為如下不同的種類：
- 從人工操作還是寫程式碼來操作的角度，可以分為手工測試和自動化測試；
- 從是否需要考慮系統的內部設計角度，可以分為白盒測試和黑盒測試；
- 從測試物件的級別，可以分為單元測試、整合測試和端到端測試；
- 從測試驗證的系統特性，又可以分為功能測試、效能測試和壓力測試。
單元測試是一種自動化測試，測試程式碼和被測的物件非常相關，比如測試React元件的程式碼就和測試jQuery的外掛的程式碼完全不是一回事。
單元測試程式碼一般都由編寫對應功能程式碼的開發者來編寫，開發者提交的單元測試程式碼應該保持一定的覆蓋率，而且必須永遠能夠執行通過。可以說，單元測試是保證程式碼質量的第一道防線。
開發者應該注意：
首先，即使單元測試覆蓋率達到100%，也不表示程式是沒有bug的；
另外，程式架構的可測試性非常重要，需要架構能把程式拆分成足夠小到方便測試的部分，只要每個小的部分被驗證能夠正確的各司其職，組合起來能夠完成整體功能，那麼開發者編寫的單元測試就可以專注於測試各個小的部分就行，這就是更高的可測試性。
二、單元測試環境搭建
- 單元測試框架
- 單元測試程式碼組織
- 輔助工具
- 單元測試框架
常見的是以下兩種：- 用Mocha測試框架，但是Mocha並沒有斷言庫，所以往往還要配合Chai斷言庫來使用，也就是Mocha+Chai的組合。
- 使用React的本家Facebook出品的Jest，Jest自帶了斷言等功能，相當於包含了Mocha和Chai的功能，不過Jest和Chai並不一致。
create-react-app建立的應用中自帶了Jest庫，Jest會自動在當前目錄下尋找滿足下列任一條件的JavaScript檔案作為單元測試程式碼來執行：
- 檔名以.test.js為字尾的程式碼檔案；
- 存於test目錄下的程式碼檔案
- 單元測試程式碼組織
單元測試程式碼的最小單位是測試用例，每一個測試用例考驗的是被測試物件在某一特定場景下是否有正確的行為。在Jest框架下，每個測試用例用一個it函式代表，it函式的第一個引數是一個字串，代表的是測試用例名稱，第二個引數時一個函式，包含的就是實際的測試用例的過程。一個很簡單的單元測試用例程式碼如下：
it(’should return object when invoked',()=>{
//增加斷言語句
});
組織多個it函式例項，即測試套件。
在Jest中用describe函式描述測試套件，一個測試套件的程式碼如下：
describe('actions'，()=>{
it('should return object when invoked',()=>{});
//可以有更多的it函式呼叫
})
describe函式包含與it函式一樣的引數，兩者主要的區別就是describe可以包含it或者另一個describe函式呼叫，但是it卻不能。
describe中有如下特殊函式可以幫助重用程式碼：
- beforeAll：在開始測試套件之前執行一次；
- afterAll：在結束測試套件中所有測試用例之後執行一次；
- beforeEach：每個測試用例在執行之前都執行一次；
- afterEach：每個測試用例在執行之後都執行一次
- 輔助工具