全棧開發人員的特點是能夠從頭到尾交付并發布一個特性。教程和書籍常常側重于搭建全棧開發環境和讓測試能夠進行所需要的“管件（plumbing）”（我綜合運用了Angular、Rails、Bootstrap和Postgres）。但對于如何貫穿整個Web開發棧進行應用程序測試，卻常常缺少指導。讓我們深入研究下這篇文章。我們將學習如何充分利用端到端測試，包括對測試什么以及如何保證那些測試的可靠性和可維護性進行指導。我們還將談及單元測試以及它們在端到端測試策略中的作用。但首先，我們要理解編寫測試的根本目的。\

從根本上講，測試是為了確保應用程序的行為符合開發者的意愿。它們是自動化的腳本，執行代碼并檢查其行為是否符合預期。測試編寫得越好，就越可以依賴它們為部署把關。如果測試不充分，就需要一個QA團隊或者發布有缺陷的軟件（兩者均意味著用戶獲得價值的速度比理想情況慢許多）。如果測試充分，就可以自信而快速地發布，不需要批準或者像QA那樣緩慢的人工過程。\

對于編寫的測試，還必須權衡未來的可維護性。應用程序會變，因此測試也會變。在理想情況下，測試的修改與軟件的修改是成正比的。如果你修改了一條錯誤信息，那么你不會希望大量重寫測試套件。但是，如果你徹底地修改了一個用戶流程，那么可以預料，將有大量的測試需要重寫。\

實際上，這意味著你無法將所有測試都作為端到端的全面集成測試，但是你也不能只進行少得可憐的單元測試。這就關乎如何達成那種平衡。\

測試的類型

\

測試的種類很多，但對于本文而言，我們就談論兩類：端到端測試和單元測試。\

端到端測試模擬用戶行為。在Web應用程序中，他們會啟動服務器，打開瀏覽器，到處點擊，斷言瀏覽器中發生了特定的事情，讓我們相信功能可以正常運行。這些測試會給我們巨大的信心，但是它們緩慢而脆弱，并且同用戶界面緊密地耦合在了一起。\

單元測試根據代碼單元的公共API運行它們。這些測試需要創建一個類的實例，使用特定的輸入調用它的方法，斷言被調用的方法達到了預期的效果（通常是返回了預期的輸出）。這些測試快速而穩定，并且不會同系統的其他部分緊密地耦合在一起。不過，它們無法讓你相信整個系統可以正常運行——只是測試過的代碼單元可以正常運行。\

構建一項特性的任務就是要在兩類測試之間找到恰當的平衡點。如果端到端測試太多，那么未來修改應用程序就會痛苦而緩慢。如果太少，那么一些不易覺察的缺陷就會進入到生產環境，即使快速測試套件的代碼覆蓋率為100%。\

從用戶體驗入手

\

你的軟件是向某個用戶提供服務，因此，那個用戶應該推動你的工作。我不建議使用測試來設計用戶體驗，因此，要在編寫測試之前弄清楚用戶將如何使用軟件（要么通過試驗性代碼，要么同一名設計師一起工作）。一旦弄清楚了，就可以開始工作了。\

在理想情況下，你將為用戶體驗的某個部分創建端到端的測試，并編寫代碼讓其通過測試。在編寫那些代碼的時候，你會創建單元測試，具體化需要創建或修改（通常是后者）的代碼的規范。\

問題是，編寫沒有用戶界面工件（HTML）可供參考的、端到端的失敗測試很難。這是因為，大部分端到端測試的形式都是：\

找到頁面上的某個元素； \

通過某種方式同它交互； \

證實交互成功； \

重復上述過程直到測試結束。

這意味著，圍繞要發生交互的用戶界面元素（DOM對象），你需要有一些規范。當把以JavaScript為基礎的交互設計考慮在內時，如果不實際地構建界面，至少是部分地構建，就更難測試了。\

為此，要讓一個粗略的UI輪廓在瀏覽器中運行起來。使用預先準備好的數據，并且不需要考慮備選流程——一次專注于一件事。它運行起來以后，就可以編寫測試了。\

在這樣做的時候，有兩點需要考慮：這個特性需要測試嗎？如果需要，該如何測試？\

測試什么

\

雖然在編程上沒有愉快路徑，但用戶經歷的代碼路徑要比代碼的可能路徑少許多。例如，當用戶購買一款產品，根據用戶地址、選擇的發貨方式或者以前的購買歷史，我們可能會用不同的方式處理訂單。在所有情況下，用戶的體驗都是一樣的，這樣,在用戶看來，流程只有一個。\

這時，你的目標是測試所有的用戶流程。你需要一個測試套件，模擬一個用戶做你想要并希望他做的事，并斷言你想要提供給該用戶的所有體驗都工作正常。\

假如你已經知道要測試什么，那應該如何進行呢？\

如何進行端到端測試

\

如果修改了一個流程，那么就要修改那個流程的測試。由于端到端測試模擬用戶活動，所以不需要為想要斷言的每件事情都編寫一個測試。如果用戶應該在結算界面上看到三段重要的信息，就不需要編寫三個測試——一個測試檢查所有三段信息就足夠了。因此，當修改一個現有的用戶體驗時，要找一個現有的、可以改進的測試。\

否則，就需要一個新的測試。記住，你的目標是模擬用戶要做的事情。務必要對如何組織測試中的導航和行為開誠布公。用戶真地會直接導航到某些深層鏈接嗎？或者他們會點擊某個公用的開始頁面從而到達他們需要到達的地方嗎？\

這很難做，尤其是通常要使用最少的標記實現該功能。測試需要定位特定的DOM元素同其交互，而準確找到你想要同其交互的元素并不總是很簡單（或者可能）。你需要“標識（signpost）”。\

標識是專門插入DOM中用于定位感興趣的元素的。要盡早確定這些標識如何發揮作用。不應該使用原本用于樣式化的CSS類來定位DOM元素。這樣做意味著前端開發人員改變類名就會破壞測試。也不應該使用被JavaScript代碼使用的CSS類或數據屬性（比如前綴為js-的類）。這會帶來同樣的破壞。\

使用前綴為test-的CSS類或者前綴為data-test-的屬性是兩種常用的技術：

\u0026lt;section class=\"component dark test-checkout-confirmation\"\u0026gt;\ \u0026lt;!-- ... --\u0026gt;\\u0026lt;/section\u0026gt;\\\u0026lt;!-- 或者 --\u0026gt;\\\u0026lt;section class=\"component dark\" data-test-checkout-confirmation\u0026gt;\ \u0026lt;!-- ... --\u0026gt;\\u0026lt;/section\u0026gt;\\

這可能看上去讓人不舒服……也確實是。但是，與將測試耦合到內容或者展示類相比，這就不那么令人討厭了。這里，你需要尋求一種平衡——不要盲目地使用data-test屬性標記每個元素。例如，如果你想點擊一個購買特定產品的按鈕，那么你真正需要的只是定位某個包含那款產品及購買按鈕的元素。

\u0026lt;article data-test-product=\"1234\"\u0026gt;\ \u0026lt;!-- a ton of markup --\u0026gt;\ \u0026lt;input type=\"submit\" name=\"Purchase\" value=\"Purchase\"\u0026gt;\\u0026lt;/article\u0026gt;\\u0026lt;article data-test-product=\"5678\"\u0026gt;\ \u0026lt;!-- a ton of markup --\u0026gt;\ \u0026lt;input type=\"submit\" name=\"Purchase\" value=\"Purchase\"\u0026gt;\\u0026lt;/article\u0026gt;\\

添加data-test-product屬性后，你就能夠使用一個像[data-test-product='1234'] input[type='submit']這樣的CSS選擇器定位產品1234的購買按鈕了。\

這意味著你必須修改只為測試而存在的標記，就是說，為了獲得你提供給他們的用戶體驗，用戶要下載一些他們不需要的字節。這是一種平衡，但比糟糕的測試覆蓋率（對用戶的傷害遠遠超過了HTML中多一些額外的字節）要好。只是得恰到好處。\

當頁面上有改變頁面內容而又不重新加載的交互（換句話說，使用JavaScript）時，這項技術就更加重要了。\

處理交互

\

當每次點擊都重新加載頁面時，端到端測試更可靠，因為底層工具知道要等待一個頁面重新加載。當用戶交互只是改變DOM時，難度就大了，因為工具不知道什么“事情”正在發生，也就無法“等待事情完成”。\

當測試需要同一個不會根據用戶動作重新加載的頁面交互時，就需要一種方法能夠在開始斷言發生了什么之前等待DOM操作完成。如果不等待，那么如果測試開始斷言時DOM還沒有更新，測試就會無謂地失敗。\

就像在標記中使用標識定位要操作的DOM元素一樣，我們也可以把它們用在這里。任何新增或變化的標記都應該有某種在交互失敗或沒有發生的情況下不會出現的標識。換句話說，你不必為了等待DOM事件而在測試中進行休眠調用——DOM中應該包含可供測試顯式等待的標識。\

例如，假設我們想要測試一個動作為用戶生成了一條成功的消息。假設實現方法是發出一個AJAX請求，當調用結束時向DOM中插入一條消息。一個基本的實現可以像下面這樣做：

function purchase(productId) {\ $.post(\ \"/products/\

總結

以上是生活随笔為你收集整理的全栈测试：平衡单元测试和端到端测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。