一、單元測試的原則
從不同的角度，可以將測試劃分爲如下不同的種類：
- 從人工操作還是寫代碼來操作的角度，可以分爲手工測試和自動化測試；
- 從是否需要考慮系統的內部設計角度，可以分爲白盒測試和黑盒測試；
- 從測試對象的級別，可以分爲單元測試、集成測試和端到端測試；
- 從測試驗證的系統特性，又可以分爲功能測試、性能測試和壓力測試。
單元測試是一種自動化測試，測試代碼和被測的對象非常相關，比如測試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：每個測試用例在執行之後都執行一次
- 輔助工具