20 lines
3.7 KiB
Markdown
20 lines
3.7 KiB
Markdown
# 自动化测试
|
||
|
||
## 为何选择Puppeteer作为端到端测试工具？
|
||
|
||
当前存在丰富的网络端到端自动化测试工具生态。因此常有人提出疑问："为何Gutenberg选用[Puppeteer](https://developers.google.com/web/tools/puppeteer/)而非([Cypress](https://cypress.io/)、[Selenium](https://www.selenium.dev/)、[Playwright](https://github.com/microsoft/playwright)等)？"考虑到端到端测试在构建结果方面存在历史性的不稳定性，在评估工具提供的价值是否超过维护成本时，这个问题显得尤为关键。虽然我们应始终保持重新评估早期决策的开放态度，但无论是过去还是现在，Puppeteer始终是端到端测试方案中的最佳折中选择。
|
||
|
||
其优势包括：
|
||
|
||
- **与现有测试框架的互操作性**。Puppeteer"仅"是一个控制Chrome浏览器的工具，并不预设测试环境的集成方式。虽然这需要额外确保测试环境的可用性，但也使其能够灵活适配现有配置。Gutenberg得以在单元测试和端到端测试中持续使用Jest框架。这与Cypress等其他方案形成鲜明对比——后者提供自成体系的测试框架和断言库作为一体化解决方案。
|
||
- **表达力强且可预测的API**。Puppeteer在底层浏览器行为访问与现代化JavaScript[异步/等待语法](https://developer.mozilla.org/zh-CN/docs/Learn/JavaScript/Asynchronous/Async_await)的命令发布/响应等待之间实现了精妙平衡。相较之下，其他方案要么不支持原生异步功能，要么未开放直接浏览器访问权限，要么采用自定义领域特定语言来表达浏览器命令和断言。尽管Puppeteer主要针对Chrome浏览器在跨浏览器覆盖方面存在局限，但有限的浏览器目标反而能提供更一致的测试结果，并确保代码在浏览器环境中获得更可靠的评估。
|
||
- **暴露问题而非掩盖缺陷**。许多替代方案提供自动等待网络请求完成或页面元素异步加载的功能。虽然这为处理不可预知的延迟提供了便利，但也可能无意间掩盖真实存在的用户体验问题。例如，若某个元素仅在网络请求或计算完成后才会显示，开发者很容易忽略这些延迟可能导致用户遭遇不可预测的挫败体验（[案例](https://github.com/WordPress/gutenberg/pull/11287)）。鉴于开发者通常在高性能设备和稳定网络环境下测试，低端设备或不稳定网络连接下的韧性考量往往被忽视。Puppeteer通过显式的`waitFor*`表达式迫使开发者正视这些延迟，使测试更贴近真实用户的体验场景。
|
||
- **调试功能**。当测试失败时，必须具备直观的问题诊断与解决手段。虽然相比竞品功能较为基础，但Puppeteer确实提供了"有头模式"（可见浏览器界面）和延迟操作等调试选项。结合其与原生语言/运行时功能（如调试器语句或断点）的良好互操作性，为开发者提供了充分的调试支持。
|
||
|
||
更多背景信息请参阅：
|
||
|
||
- [测试概览：端到端测试](/docs/contributors/code/testing-overview.md#端到端测试)
|
||
- [测试：Puppeteer端到端测试实验](https://github.com/WordPress/gutenberg/pull/5618)
|
||
- 在早期迭代中，贡献团队曾选择Cypress进行端到端测试。该拉取请求阐述了该方案存在的问题，并提出了向Puppeteer迁移的初步建议。
|
||
- [JavaScript聊天纪要：2020年1月28日](https://make.wordpress.org/core/2020/02/04/javascript-chat-summary-january-28-2020/)
|
||
- Playwright是由多位Puppeteer原始贡献者打造的新方案。它提供更广泛的浏览器覆盖和更可靠的测试表现。尽管撰写本文时该工具尚处早期开发阶段，但已引起将其作为未来端到端测试方案的评估兴趣。 |