爲何puppteteer比selenium好?

在今年年初，我在公司使用Selenium編寫客戶端測試。對於那些主要使用Scala編寫的開發人員來講，這是很好的事。問題在於學習Scala和Selenium是開發人員編寫端到端測試的高標準。咱們有不少開發人員幾乎都是用TypeScript編寫的。做爲Scala的新手，對新功能進行客戶端測試很是困難，以致於一般不會編寫測試。
當我發現Puppeteer時，它彷佛是解決這個問題的正確工具。開發人員能夠用TypeScript編寫測試，這是他們更熟悉的語言。咱們已經使用Jasmine編寫單元測試，所以使用Jasmine建立Puppeteer測試的能力是一個明顯的勝利。Devs還能夠在運行測試時鏈接Chrome DevTools，這樣他們就可使用他們熟悉的調試器。全部這些功能看起來都很是適合下降編寫客戶端測試的條件。Puppeteer也比Selenium有一些優點。

更簡單的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的緣由。

網絡攔截

這是Puppeteer對Selenium的最強大優點。您的測試代碼能夠記錄，修改，阻止或生成瀏覽器發出的請求的響應。乍一看，這彷佛不是一個很是有用的功能，但它有助於解決許多難以解決的問題。

測試處理失敗的請求

經過讓Puppeteer有選擇地使某些請求失敗，您能夠驗證您的產品在這些狀況下是否正常失敗。您可使用此過程在上載失敗時驗證錯誤消息是否正確。若是圖像未加載，您能夠驗證頁面佈局是否會崩潰。

模擬第三方服務

我有使用此類別中的網絡攔截的第一手經驗。咱們想爲Salesforce塊編寫一些自動化測試。問題在哪呢？咱們的Salesforce插件依賴於調用Salesforce API。若是咱們編寫測試來登陸現有的Salesforce賬戶來運行這些測試，咱們會遇到一些問題：咱們必須依賴與Salesforce創建可靠鏈接的測試機器，Salesforce GUI中的更改將致使咱們的測試忽然失敗而且沒有任何錯誤，Salesforce能夠檢測到咱們正在以機器人身份登陸並安裝CAPTCHA或須要兩步驗證。讓人驚訝。Puppeteer爲咱們解決了這個問題。咱們可以編寫一個在本地運行的模擬Salesforce API。任何對Salesforce的請求都會被Puppeteer截獲，而且僞造的數據會在其位置返回。使用這種方法，

測試離線模式

Puppeteer也能夠模擬離線。您能夠編寫測試以確保您的產品正確處理失去Internet鏈接的問題。這種能力對於爲咱們最近添加到產品中的離線模式功能編寫單元測試相當重要。咱們可以建立單元測試以驗證更改是否已脫機保存，而且當鏈接返回時，更改將保存到服務器。若是沒有這個功能，咱們將徹底依賴於單元測試或試圖以最不能測試咱們的離線功能的方式僞造離線模式。

調試

因爲Puppeteer能夠收到來自瀏覽器的全部請求和響應的通知，所以您也能夠簡單地記錄該信息 - 這在嘗試診斷構建服務器上運行的測試失敗的問題時很是有用。做爲構建系統的一部分，當咱們的一個Puppeteer測試失敗時，咱們會得到失敗時打開的全部選項卡的屏幕截圖，以及完整的控制檯日誌轉儲以及瀏覽器發出的全部請求。此信息有助於從構建報告中診斷測試失敗，而無需在本地運行它們。當測試僅在咱們的構建服務器上失敗時，它也是很是有價值的，在那裏您沒有看到測試運行而且只得到測試結果。

單個瀏覽器，單一語言

這聽起來像是一個缺點。若是我正在寫一篇關於爲何Selenium比Puppeteer更好的文章，我確定會寫到一點就是Selenium能夠爲你提供更多關於你想要使用什麼語言的選項，同時更重要的是，Selenium可讓你在多個瀏覽器上運行你的測試。那麼爲何Puppeteer缺乏這些功能我還要給它加分呢？由於這些功能須要付費。
在Selenium上搜索代碼示例時，您常常會找到另外一種語言的示例。您能夠在線搜索並找到關於如何使用Selenium的優秀教程或一個顯示您想要完成的內容的優秀代碼片斷，但它們可能使用您不使用且不熟悉的語言。
此外，Selenium給出的「一次編寫，在任何瀏覽器上運行」的承諾在現實世界中並不老是如此。出於某種緣由，一些測試將在一個瀏覽器中傳遞而在另外一個瀏覽器中沒有明確的緣由。不一樣瀏覽器驅動程序中的錯誤可能會阻止測試在全部瀏覽器上可靠運行。若是您願意投入額外的工做，能夠在多個瀏覽器上運行測試，但只須要針對單個瀏覽器，這能夠大大簡化您的開發負載。

因此你應該選擇selenium而不是Puppeteer嗎？

對於個人狀況，我認爲選擇Puppeteer而不是Selenium是正確的。我並非說每一個人都應該捨棄Selenium。咱們仍然爲那些喜歡它們的人編寫和維護Selenium測試。我也不建議每一個人都選擇Puppeteer而不選擇Selenium。我之因此選擇Puppeteer是由於它提供了更簡單的Javascript執行，網絡攔截以及更簡單，更集中的庫。我但願這些要點很是有用，這樣若是您但願進行客戶端測試，就能夠作出明智的選擇。

看以後

點贊，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓-_-）
關注公衆號「新前端社區」，享受文章首發體驗！
每週重點攻克一個前端技術難點。