Test double 測試替身

測試替身最主要是透過封裝好的函式來協助開發者模擬一些函式、功能、模組所返回的值。

像是 Mocha.js 就會搭配像是 Sinon.js 這一類的隔離庫來使用測試替身。而 Jest 本身核心概念是屬於 batteries-included 類型的框架（即為你需要的功能，框架都盡量幫你準備好了），因此 Jest 在模擬測試替身上則是看 Jest 本身的 Mock API 即可！

setup、teardown

在執行測試時，有時候會需要初始化一些基本資料以供測試進行，並且在測試完畢的時候要讓測試後的資料復原、整理。

而 Jest 在這方面提供的 API 如下：

• describe()：測試套件，可以針對測試鉤子形成作用域（scope）並描述該部分的測試情境。
• test()：測試案例，用以描述該筆正在進行的測試內容與設定相關測試條件。（也可以使用別名 it()）
• beforeAll()：針對該測試套件的作用域，在第一筆測試案例開始前執行一次。
• afterAll()：針對該測試套件的作用域，在最後一筆測試案例結束後執行一次。
• beforeEach()：針對該測試套件的作用域，在每個測試案例開始前執行一次。
• afterEach()：針對該測試套件的作用域，在每個測試案例結束前執行一次。

Asynchronous

由於 JavaScript 在瀏覽器的宿主環境裡擁有單線程（single thread）的特性，使得在程式執行時期（Run time）中一些有關非同步（Asynchronous）的操作會等到主線程（Main thread）整個操作結束後才會回來執行處在任務序列（Event queue）中的非同步操作。

因此在測試中，如果遇到有關非同步的操作時，測試程式碼的執行順序（主線程）會先於任務序列，造成測試還未來得及收到非同步執行後的結果，進而導致測試失敗的產出。

我們能做的做法便是要將測試程式碼運行結束的時間，拖延至任務序列當中，讓測試套件（Test suit）中非同步的結果產出之後，才來進行測試中的斷言。

而在 Jest.js 解決這一類非同步測試的問題時，有提供了實際 API 的作法以供參考：

• callback function 類
• promise 類
• async / await 類

斷言 Assertion

在測試庫中，斷言（assertion）是一個很重要的概念，意思即為開發程式中執行完畢時，程式碼執行結果應與斷言所設定的結果一致，否則該處斷言碼會拋出錯誤的意思。你可能已經在某些情況下「斷言」過好幾次了，例如在 JavaScript 裡面使用全等比較（===）來比較兩者的資料類型是否一致，這便是斷言。而在 Jest.js 框架中，Jest 選擇的是使用 Matchers 配對器這個名稱，兩者其實在概念上是差不多的東西。

Jest.js 中的配對器（Matchers），主要採用的是 expect() 的方法，但 Jest.js 中的 expect 與 Node.js 和其他斷言庫（如 Chai.js）中的 expect() 是不一樣的，別搞混了！XD，我自認為比較好辨識 Jest 方法是當斷言中出現了 expect().toBe() 這個東西，基本上看到這個可以確認大概率是使用 Jest.js 了。

而為什麼辨識文件中是用誰家的斷言有一點小重要的點是，當你試著按照例如 Vue.js 的測試文件 Vue-test-utils 測試時，可能會遇到斷言方法 API 不一樣的情況，那麼你可能得回去翻翻其他斷言庫本身的斷言 API 文件了。

What is Jest.js

Jest.js 是由 Facebook, Inc 公司所維護的測試框架，並且支援了 Babel、TypeScript、Node.js、Vue.js、React.js、Angular.js，基本上支援了全部的現代框架，而 Jest 的核心概念 batteries-included，使得我們在使用測試要找一些資源時不太需要費力，因為，Jest 都幫你準備好了！

Run Cycle 運行週期

Mocha.js 在執行測試時，會遵循它的運行週期，只要瞭解了它的運行週期，我們便能快速掌握撰寫測試程式碼的基本架構：

What is Mocha.js

Mocha.js 是一款基於 Node.js 的 JavaScript 測試框架，用意在於使開發人員可以寫出更優雅且容易閱讀的測試程式碼，並且支援不同斷言庫來判斷程式。而彈性、多樣的配置是 Mocha.js 最大的特點，不同於像是 Jest.js 的 batteries-included 的概念，Mocha.js 只提供了最基本的測試環境，而斷言與隔離的選擇，都可以自由地搭配其他的函式庫來使用。例如：選配 Chai.js 斷言庫以及 Sinon.js 隔離庫。如此一來就能使用較自由的測試風格來撰寫測試程式碼。

SPA

今天要介紹的是對單頁式應用網站（SPA，Single Page Application） 非常重要的 Router， SPA 為何會需要 Router 來處理網頁路徑呢？這裡簡單介紹一下他們之間的關係：

在 SPA 技術被大肆使用之前，以前的網站多是採用多頁式網頁（MPA，Multiple Page Application），而兩者差異最大的地方在於向伺服器請求的東西不同。

一開始不論 SPA 還是 MPA 網站都需要使用者輸入網址，透過一個叫做 DNS 的服務器找到該網站伺服器，接著經過一連串回應後，伺服器回應給使用者一個 HTML 網頁檔案。

而 MPA 在後續轉換頁面上，則是藉由輸入的網址不同，重複以上動作向網站伺服器拿取每頁的網頁檔案，並且重新渲染每頁的內容，因此會造成網頁整個畫面都被刷新。

SPA 則是進入入口網頁（SPA 進入點）後透過 AJAX 技術，跟伺服器拿取部分資料替換內容進去；而替換的區域，小至更新收藏狀態的按鈕，大至整個頁面都被刷新，此時網址列的路徑卻仍是我們一開始進去的那個 SPA 進入點網址。

因此，SPA 網頁需要藉由 History API 來操控網址列，並且藉由前端辨識使用者輸入的網頁路徑不同，而透過前端給予使用者不同的頁面內容，這也代表著原先由後端伺服器所負責的路徑管理，將交由前端來負責辨識與處理，也使得前端的複雜度上升了一個檔次。

為了使用者的品質體驗，身為前端工程師的我們當然不會因為這種小事而被擊倒，但管理路徑上確實是不容易的事情，因此工程師們逐漸發展出一系列管理路徑的方法。而在 Vue 框架中，我們可以藉由 Vue Router 來協助處理這一類的問題，這也就是今天所要提到的內容。

前情提要

這幾天陸陸續續講解了 Vue.js 在 Vue-cli 裡偏向實作的說明，而目前我們也已經完成了一個簡單的元件，可以透過父層引用這個元件時，將需要的資料傳遞給元件，使子元件可以在不同頁面、區塊重複使用。

然而昨天有提出了一個問題，「假設今天不同頁面（不同 .vue 檔案），都要使用共同的狀態時，我們應該如何處理？」

單一元件檔 props

今天要來把昨天製作好的元件檔案拆分的更乾淨一點，昨天我們的資料都還放在元件自己本身中的 data 裡面，這樣子在 View 頁面使用時套用該元件都只會讀到元件自己本身中的資料，而我們今天要來將元件中的 data 清除乾淨，透過父層在決定要使用這個元件時，才將要輸入的資料傳遞進去。