现实中，开发人员常常没有时间编写测试，特别是单元测试，因为它需要花费很多的时间，所以很多团队放弃了。由于他们放弃了测试套件中的基础（单元测试），他们也很可能会放弃其他测试。
实际上，花一点点时间写一点点端到端（end-to-end）测试可能是一个非常划算的选择，特别是对于Web应用程序来说。最少的时间可以帮助我们解决最大的问题。例如，
- 我希望避免在新版本发布后，我的网站上出现白屏（致命的 bug，但只需要最少的时间来避免）。
- 我希望减少测试阶段或生产环境中的高级别 bug（对开发/测试团队的绩效很重要，但只需要一点时间）
- 我希望在任何情况下保持核心功能可用（取决于我们想覆盖多少核心功能，则需要相应的时间）
下面，我来演示一下如何用30行代码写一个解决上面问题的端到端测试。
选择一个端到端测试框架
市场上有很多端到端测试框架。我将在另一篇文章中进行比较，您可以先通过此图做个简要的了解。
因为playwright非常方便进行演示，所以我将在本文中选择它。
设置端到端测试
我使用 npm init playwright@latest 创建了测试项目。此外，我还安装了playwright vscode插件。下图是 playwright 创建的文件。
运行示例测试
现在，我将通过vscode插件提供的启动按钮运行示例测试。
我们可以看到浏览器被打开，并且测试通过。
我们还可以在许多地方看到测试结果。
简要总结
-
正如我们所看到的，运行测试并查看运行状态非常简单（测试期间可以打开浏览器）。
-
另外，在示例测试中，我们只需要4行代码(第一个测试用例)来验证目标网站是否可用，是否在向用户显示空白页面。如果我们将测试部署到CI，QA和最终用户遇到空白页面的机会将大大降低。
我们还可以查看生成的测试报告（注意，这些都是自带的，我们甚至都没有显式的配置）
更进一步
如果playwright首页是我们自己的产品，那么我们可以总结一下核心功能或冒烟用例
- 首页应该是可用的，不会白屏
- 点击"Docs"应该可以进入文档页面
- 文档页面应该显示正确的文档
实际上，这个页面还有很多其他功能，但由于它是一个文档网站，核心功能就是它可用并提供正确的内容。
如果其他功能出现问题，它可能并没有那么重要，即使在生产环境中遇到，也很有可能不需要像在1小时内紧急修复那样让人紧张。
这也是实际情况，并不是每件事情、每个模块都有相同的重要性。
当然如果你有足够的时间，自然可以去覆盖更多的情况并编写单元测试。
总之，假如我是站长，上面的 3 点功能，对我来说，就是最重要的核心功能。转换成代码，总共不到30行（包括空行）。
在实际应用中，为了更容易定位元素，我们可以在测试元素中添加类似data-testid的属性，然后可以使用类似以下代码：
ts
await page.getByTestId('nav-docs').click();而不是
ts
await page.locator('.navbar__link').getByText('Docs').click();这样可以更轻松地编写端到端测试，代码的可读性也会更高。
最后
我们可以把这个端到端测试部署到 CI 环境（Jenkins、Github Actions等）。我们可以在这里找到相关文档。
如果我们把 CI 配置上，通过这个例子，我们只用了 30 行代码，就可以保证我们的每一次推送、合并都不会破坏核心功能，由代码导致的核心功能故障的风险也会被大大降低。
实际上，编写端到端测试不仅对开发工作有好处，还可以帮助解决生活中的问题。毕竟，它的核心是编写自动化脚本，生活中有太多的事情，可以通过自动化脚本来操作了。
现在，你是否想尝试一下编写一些端到端测试呢？