只改了一行 CSS，另一个页面上的按钮就悄悄塌了。没有测试失败，代码审查也没看出来，一周后才从用户那里听说。小团队应该都遇到过这种 bug。
教科书式的答案是多写单元测试。我带着一个小开发团队，说实话，给每个组件、每种布局状态都写单元测试是我们负担不起的奢侈。我们靠的是视觉测试：给页面截图，和已知正常的基线对比，不该动的像素动了就在构建里报出来。考虑到投入的精力，我还没见过更划算的办法。
截图为什么这么值#
它的魅力在于你不用写的那些东西。视觉测试不给单个元素写断言，而是把整个页面当成一个整体来判断。布局偏移、颜色变化、响应式破损、元素重叠——恰恰是代码审查容易漏掉、单元测试又很难覆盖的问题，现在全都以 diff 的形式出现在 PR 里。
维护成本也几乎为零。基线设一次，之后每个 PR 自动跑，每次结果一致。有意的 UI 改动？更新基线，继续干活。无意的改动？diff 就在 PR 里摆着，不用再一页一页点过去找问题。
它替代不了单元测试#
单元测试验证逻辑，截图验证外观，最终两个都要有。但如果团队小，必须选择先把时间投在哪里，按单位搭建时间算，视觉测试给的覆盖面最大。我的原则是：坏了会真正出事的业务逻辑用单元测试，其余交给视觉测试。
整套系统就这些：基线、每个 PR 的 diff，偶尔点一下“是的，这是有意的改动”。就这点投入来说，它抓到的问题多得不像话。
更多信息和实用链接#
Visual Testing with Playwright#
Playwright 的快照测试文档：截取整页或特定元素，与基线对比，并在有意改动后管理基线更新。 Visual Testing with Playwright
Best Practices for Testing with Playwright#
Playwright 关于数据库相关测试的建议：隔离测试数据、测试后清理、保持测试相互独立，让测试套件稳定可靠。 Best Practices for Testing with Playwright