本文翻譯自 The Front-End Test Pyramid: How to Rethink Your Testing
如果你在測試前端引用茎用，你應當知道前端測試金字塔晤揣。
本文中我們將關注何為前端測試金字塔刀森，以及如何使用它來創(chuàng)造泛用的測試套件。
前端測試金字塔
前端測試金字塔是一種關于構建前端測試套件的描述俏讹。
理想化的測試套件由單元測試、快照測試和端對端測試組成畜吊。
這是一個針對前端引用測試的特殊版本的測試金字塔泽疆。
本文中，我們將介紹每一種測試類型玲献。首先殉疼，我們要創(chuàng)建一個用于例子的測試套件
應用
為了進一步了解前端測試金字塔，我們先要了解如何測試一個網(wǎng)絡應用青自。
測試應用是一側簡單的模態(tài)框株依。點擊按鈕打開模態(tài)框，再點擊模態(tài)框上的OK按鈕關閉延窜。
完成后的模態(tài)框（The finished app）
我們將構建基于組件化框架的應用恋腕。不必擔心具體實現(xiàn)，在文中我們將保持這種抽象性逆瑞。
測試應用由按鈕組件荠藤、模態(tài)框組件和應用組件這三個組件構成。
我們要寫的第一個測試是單元測試获高。在前端測試金字塔中哈肖，我們的大部分測試為單元測試。
單元測試
單元測試測試代碼庫單元念秧。
單元測試調取函數(shù)或者單元淤井，確保其能返回正確結果。
在我們的應用中摊趾，組件就是單元币狠。所以我們將為按鈕及模態(tài)框寫單元測試，同時砾层，我們不需要寫應用組件的單元測試因為它不含邏輯（只是一個容器）漩绵。
單元測試會淺渲染組件并斷言他們會在互動時正確執(zhí)行。
淺渲染指渲染單一層次的組件肛炮。這能保證我們只測試我們要測試的組件或單元止吐，不包括子組件。
在我們的測試中侨糟，我們觸發(fā)組件的行為并檢查組件的表現(xiàn)是否符合預期碍扔。
我們無須了解具體代碼，而是依照組件的需求如下進行測試：
- 模態(tài)框有一個is-active類當displayModal字段為true
- 模態(tài)框沒有一個is-active類當displayModal字段為false
- 模態(tài)框調取toggleModal方法當“成功”按鈕被點擊
- 模態(tài)框調取toggleModal方法當“刪除”按鈕被點擊
- 按鈕調取toggleModal方法當自身被點擊
我們的測試會淺渲染組件并檢查組件是否按需求執(zhí)行秕重。
之所以單元測試是測試套件的大頭是因為以下原因：
單元測試運行迅速
一個測試套件能在幾秒內運行數(shù)百個單元測試蕴忆。
這讓單元測試在開發(fā)中非常游泳。在重構代碼時悲幅，我們能修改代碼套鹅，并用單元測試檢查這些修改是否有bug讓組件無法運行站蝠。我們將在幾秒中知道這些如果其中一個單元測試報錯的話。
單元測試是顆磷柯梗化的
換言之菱魔，單元測試的泛用性非常強。
如果單元測試失敗吟孙，運行被打斷的單元測試會告訴我們?yōu)楹问 ?br>
單元測試善于檢查我們應用運行的細節(jié)是否完善澜倦。它們是我們開發(fā)中最好的工具，特別是你按照測試驅動的開發(fā)時杰妓。
但是單元測試不能測試一切情況藻治。
為了保證我們渲染的樣式是正確的，我們需要使用快照測試巷挥。
快照測試
快照測試是旨在獲取你渲染出的組件的的截圖并與同一組件之前的截圖進行比較的測試桩卵。
Javascript上進行快照測試的最佳方式是使用Jest。
不同于獲取渲染出的組件的截圖倍宾，Jest獲取渲染出的組件標記的快照雏节。這使得Jest的快照測試比傳統(tǒng)的快照測試更快捷。
你需要添加如下代碼以便在Jest中注冊一個快照測試：
const renderedMarkup = renderToString(ModalComponent)
expect(renderedMarkup).toMatchSnapshot()
一旦你注冊了一個快照高职，Jest會打點之后的一切钩乍。每次單元測試運行都會生成一個快照并且與之前的快照進行比對。
如果快照出現(xiàn)不同怔锌，Jest會跑出一個錯誤并且表示出變化的位置寥粹。開發(fā)者接著能手工檢查且沒有類會被意外刪除。
在下面的測試里埃元，有人從<footer>上刪除了modal-card-foot類涝涤。
A failing snapshot test
快照測試是一種檢查樣式?jīng)]有被改變以及標示組件的方法。
如果通過了快照測試亚情，可知我們的代碼沒有影響到組件的顯示妄痪。
如果測試失敗了哈雏，可知我們知道我們已經(jīng)影響到了組件的渲染并且可以手工檢查樣式是否正確楞件。
你應該對每個組件進行至少一次快照測試。一個典型的快照測試渲染帶狀態(tài)的組件來檢查它渲染得正確與否裳瘪。
現(xiàn)在我們已經(jīng)有了單元測試和快照測試土浸，是時候來了解端對端測試了。
端對端測試
端對端測試是高級測試彭羹。（高級指層次的高級黄伊，即將組件看作黑箱）
端對端測試展現(xiàn)與我們手工測試所做的有相同的行為。
在我們的應用中有一個用戶行為流程派殷。當用戶點擊按鈕時模態(tài)框打開还最，當他們點擊模態(tài)框上的按鈕時關閉墓阀。
我們能寫一個端對端測試時就按這個流程進行。測試會打開瀏覽器拓轻，導航到頁面，然后進行操作來確保應用的行為是正確的。
這些測試能告知我們，我們的單元測試是同等正確的。它讓我們對于應用的主要功能的運行有了更大的信心乌庶。
對于JS應用的端對端測試有以下幾種方式，例如test cafe之類的能在瀏覽器上記錄你的行為然后重復它們作為測試的軟件契耿。
也有項目如nightwatch來讓你用js寫測試。我會推薦你去使用nightwatch這類框架搪桂。它簡單易學并且進行測試時運行速度比記錄測試快透敌。
換言之，用nightwatch測試相對還是慢的踢械。一個包含200個測試用例的套件需要幾秒來運行撵术，一個有200個端對端測試的套件則要花幾分鐘划滋。
其他的端對端測試的問題是它們能難debug埃篓。當一個端對端測試失敗了想邦，很難去找出失敗的原因，這是因為因為它涉及到了很多個功能。
結尾
想要有效率地測試基于網(wǎng)絡應用的前端組件茫蛹，你需要單元測試柬采、快照測試和端對端測試這三種測試肩刃。
你應當對每個組件進行數(shù)次單元測試大州，每個組件一到兩次快照測試和幾個互聯(lián)的組件間一到兩次端對端測試排嫌。
總之單元測試占測試中的大多數(shù)遣钳，你會有一些快照測試和一些端對端測試扰魂。
如果你按照前端測試金字塔測試，你會用一個殺手級的測試套件創(chuàng)建一個
可維護的網(wǎng)絡應用蕴茴。
參見 example repository of the app with snapshot tests, unit tests, and end to end tests on GitHub.
