教科书式的答案是多写单元测试。我带着一个小开发团队，说实话，给每个组件、每种布局状态都写单元测试是我们负担不起的奢侈。我们靠的是视觉测试：给页面截图，和已知正常的基线对比，不该动的像素动了就在构建里报出来。考虑到投入的精力，我还没见过更划算的办法。

截图为什么这么值

#

它的魅力在于你不用写的那些东西。视觉测试不给单个元素写断言，而是把整个页面当成一个整体来判断。布局偏移、颜色变化、响应式破损、元素重叠——恰恰是代码审查容易漏掉、单元测试又很难覆盖的问题，现在全都以 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