为何puppeteer比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执行，网络拦截以及更简单，更集中的库。我但愿这些要点很是有用，这样若是您但愿进行客户端测试，就能够作出明智的选择。

看以后

点赞，让更多的人也能看到这篇内容（收藏不点赞，都是耍流氓-_-）
关注公众号「新前端社区」，享受文章首发体验！
每周重点攻克一个前端技术难点。