引言
在今年年初，我在公司使用Selenium編寫客戶端測試。對於那些主要使用Scala編寫的開發人員來說，這是很好的事。問題在於學習Scala和Selenium是開發人員編寫端到端測試的高標准。我們有很多開發人員幾乎都是用TypeScript編寫的。作為Scala的新手，對新功能進行客戶端測試非常困難，以至於通常不會編寫測試。
當我發現Puppeteer時，它似乎是解決這個問題的正確工具。開發人員可以用TypeScript編寫測試，這是他們更熟悉的語言。我們已經使用Jasmine編寫單元測試，因此使用Jasmine創建Puppeteer測試的能力是一個明顯的勝利。Devs還可以在運行測試時連接Chrome DevTools，這樣他們就可以使用他們熟悉的調試器。所有這些功能看起來都非常適合降低編寫客戶端測試的條件。Puppeteer也比Selenium有一些優勢。
目錄：
- 更簡單的JavaScript執行
- 網絡攔截
- 測試處理失敗的請求
- 模擬第三方服務
- 測試離線模式
- 調試
- 單個瀏覽器，單一語言
- 所以你應該選擇selenium而不是Puppeteer嗎？
1）、更簡單的JavaScript執行
Selenium和Puppeteer的一個強大功能是能夠在瀏覽器中運行JavaScript。這個功能的使用幾乎是無窮無盡的，在Puppeteer中使用這個功能幾乎是毫不費力的 比較下面這兩段代碼： Scala + Selenium
val evalResult = Json.parse(driver.executeAsyncScript(“””
var callback = arguments[arguments.length - 1];
asyncFunction().then(callback);
“””).asInstanceOf[String])
TypeScript + Puppeteer
const evalResult = await page.evaluate(() => asyncFunction());
TypeScript版本可以更簡單，並具有一些額外的優勢。首先，TypeScript版本自動處理異常。如果AslenFunction在Selenium版本中失敗，則不會出現錯誤; 相反，它會超時。您可以，也可能應該創建一個包裝函數，以簡化調用JavaScript並正確處理錯誤，如果您使用Selenium。但是，由於基礎實現已經更簡單，Puppeteer在這里是更好的選擇。無需修改界面。
Puppeteer版本還具有TypeScript檢查類型的優勢。您可以聲明evaluate內部使用的函數和變量，如果您有語法或類型錯誤，TypeScript將捕獲這些錯誤。在Selenium中，在嘗試運行測試之前，您不會捕獲錯誤。
這些優勢的核心歸結為讓測試驅動程序使用與瀏覽器相同的語言。這使得連接兩者更加無縫。作為一個注釋，您可以在TypeScript中編寫Selenium測試並實現類似的無縫evaluate實現，但這不是我們的Scala代碼的選項 - 這就是為什么我將此列為我想切換到Puppeteer的原因。
2）、網絡攔截
這是Puppeteer對Selenium的最強大優勢。您的測試代碼可以記錄，修改，阻止或生成瀏覽器發出的請求的響應。乍一看，這似乎不是一個非常有用的功能，但它有助於解決許多難以解決的問題。
3）、測試處理失敗的請求
通過讓Puppeteer有選擇地使某些請求失敗，您可以驗證您的產品在這些情況下是否正常失敗。您可以使用此過程在上載失敗時驗證錯誤消息是否正確。如果圖像未加載，您可以驗證頁面布局是否會崩潰。
4）、模擬第三方服務
我有使用此類別中的網絡攔截的第一手經驗。我們想為Salesforce塊編寫一些自動化測試。問題在哪呢？我們的Salesforce插件依賴於調用Salesforce API。如果我們編寫測試來登錄現有的Salesforce帳戶來運行這些測試，我們會遇到一些問題：我們必須依賴與Salesforce建立可靠連接的測試機器，Salesforce GUI中的更改將導致我們的測試突然失敗並且沒有任何錯誤，Salesforce可以檢測到我們正在以機器人身份登錄並安裝CAPTCHA或需要兩步驗證。讓人驚訝。Puppeteer為我們解決了這個問題。我們能夠編寫一個在本地運行的模擬Salesforce API。任何對Salesforce的請求都會被Puppeteer截獲，並且偽造的數據會在其位置返回。
5）、測試離線模式
Puppeteer也可以模擬離線。您可以編寫測試以確保您的產品正確處理失去Internet連接的問題。這種能力對於為我們最近添加到產品中的離線模式功能編寫單元測試至關重要。我們能夠創建單元測試以驗證更改是否已脫機保存，並且當連接返回時，更改將保存到服務器。如果沒有這個功能，我們將完全依賴於單元測試或試圖以最不能測試我們的離線功能的方式偽造離線模式。
6）、調試
由於Puppeteer可以收到來自瀏覽器的所有請求和響應的通知，因此您也可以簡單地記錄該信息 - 這在嘗試診斷構建服務器上運行的測試失敗的問題時非常有用。作為構建系統的一部分，當我們的一個Puppeteer測試失敗時，我們會獲得失敗時打開的所有選項卡的屏幕截圖，以及完整的控制台日志轉儲以及瀏覽器發出的所有請求。此信息有助於從構建報告中診斷測試失敗，而無需在本地運行它們。當測試僅在我們的構建服務器上失敗時，它也是非常有價值的，在那里您沒有看到測試運行並且只獲得測試結果。
7）、單個瀏覽器，單一語言
這聽起來像是一個缺點。如果我正在寫一篇關於為什么Selenium比Puppeteer更好的文章，我肯定會寫到一點就是Selenium可以為你提供更多關於你想要使用什么語言的選項，同時更重要的是，Selenium可以讓你在多個瀏覽器上運行你的測試。那么為什么Puppeteer缺少這些功能我還要給它加分呢？因為這些功能需要付費。
在Selenium上搜索代碼示例時，您經常會找到另一種語言的示例。您可以在線搜索並找到關於如何使用Selenium的優秀教程或一個顯示您想要完成的內容的優秀代碼片段，但它們可能使用您不使用且不熟悉的語言。
此外，Selenium給出的“一次編寫，在任何瀏覽器上運行”的承諾在現實世界中並不總是如此。出於某種原因，一些測試將在一個瀏覽器中傳遞而在另一個瀏覽器中沒有明確的原因。不同瀏覽器驅動程序中的錯誤可能會阻止測試在所有瀏覽器上可靠運行。如果您願意投入額外的工作，可以在多個瀏覽器上運行測試，但只需要針對單個瀏覽器，這可以大大簡化您的開發負載。
8）、所以你應該選擇selenium而不是Puppeteer嗎？
對於我的情況，我認為選擇Puppeteer而不是Selenium是正確的。我並不是說每個人都應該舍棄Selenium。我們仍然為那些喜歡它們的人編寫和維護Selenium測試。我也不建議每個人都選擇Puppeteer而不選擇Selenium。我之所以選擇Puppeteer是因為它提供了更簡單的Javascript執行，網絡攔截以及更簡單，更集中的庫。我希望這些要點非常有用，這樣如果您希望進行客戶端測試，就可以做出明智的選擇。