[Day25] 測試一定要寫好寫滿?時間有限怎麼辦?
既然要寫測試,就先來了解前端常見的幾種測試類型,從最大家最常聽到的單元測試(Unit Testing)、到會整合不同 API 或元件互動的整合測試(Integration Testing),最後則是模擬使用者操作的 End to End Testing。
不同測試類型會搭配不同的測試工具,以單位測試來說,目前在前端最常用的是由 Facebook 推出的 Jest,它是 Node-based 的執行器,主要用來進行元件或函式的單元測試(unit test);若有需要針對頁面上的元素或 React 元件進行整合測試,筆者自己習慣用的是 test-library 上的 react-testing-library。最後,若是需要的進行更貼近瀏覽器環境的 end-to-end 測試的話,則可以使用 cypress 或 puppeteer。
測試的不同類型
根據不同的測試目的,會分成不同的測試類型,簡單來說可以分成三類,但筆者認為這三類的區隔並非一定壁壘分明的,是其中一種就不會是另一種。不論是哪一類型的測試,核心概念都是透過「預期結果(expect)」和「真實結果」去做比對,看看得到的真實結果是不是如同開發者所預期的,因此,如果你連預期會是如何都無法想像的話,那是完全沒辦法進行測試的。
單元測試(Unit Test)
測試的對象會是程式碼中最小的單元,通常會是自己撰寫的函式(function)、方法(method)、類別(classes)等等,也就是你預期這個 input 進去後,應該會得到什麼樣的 output。舉例來說,根據 LeetCode 的題目寫出 function 後,LeetCode 就會對你寫的 function 做許多的驗證,確保你寫的 function 在各種情況下都能滿足題目的需求,而針對個別 function 進行測試的情況就是所謂的單元測試(Unit Test) 。
這部分前端來說最常使到的工具是由 Facebook 推出的 Jest;後端則很常使用 mochajs 搭配 chai。
整合測試(Integration Test)
整合測試顧名思義就是需要「整合」,這表示測試的過程不是單一函式就能滿足,過程中可能會需要呼叫 API 獲取資料、使用其他的 library、或者和 DOM 進行整合,預期 DOM 上應該會呈現特定的 element。以 React Component 的測試來說,就比較接近這類型的測試,因為在 React Component 中,可能會去 fetch API 取得資料,取得資料後需要將資料呈現在 DOM 上。這時候如果是撰寫整合測試的話,就需要寫 mock data 來假設 API 回傳的資料內容,並在取得假資料後,檢測 DOM 有沒有如同預期的呈現出 element;這個過程中,也可以以程式的方式模擬使用者點擊、輸入內容的動作。
這部分以 React 來說最常提到的應該是 Testing Library 搭配 React Testing Library;或 enzyme。