HTML组件测试方法详解

怎么用 Playwright 断言一个 HTML 按钮是否渲染正确

Playwright 是目前最贴近真实用户视角的轻量级选择，比 Selenium 启动快、API 更稳，适合验证 DOM 结构、文本、属性、状态变化。

• 必须先确认按钮有 name 或 aria-label —— 否则自动化工具无法可靠定位，getByRole('button', { name: '提交' }) 比 querySelector('.submit-btn') 更健壮
• 检查禁用态：await expect(button).toBeDisabled()，而不是只看有没有 disabled 属性——有些组件用 class="disabled" 模拟，得结合 CSS 类或 aria-disabled="true"
• 点击后要等真实反馈：比如页面跳转、弹窗出现、DOM 新增元素，不能只写 await button.click() 就结束
• 注意 Shadow DOM：如果按钮封装在 Web Component 里，需用 shadow: true 选项或显式进入 element.shadowRoot()

为什么用 Jest + jsdom 测 HTML 组件容易漏问题

jsdom 是纯内存 DOM 环境，不执行 CSS 布局、不触发真实事件冒泡、不支持 IntersectionObserver 或 ResizeObserver，对视觉相关逻辑完全无感。

• 它会把 offsetHeight === 0 当成正常，哪怕元素被 display: none 或父容器溢出隐藏
• focus() 调用不会真正激活 :focus 样式，也无法验证键盘导航流程
• 异步加载的图片、字体、Web Worker 不会被模拟，img.naturalWidth 恒为 0
• 适合测「数据到 HTML 字符串」的纯渲染逻辑（如 React/Vue 的 snapshot），不适合测「HTML 到用户可见行为」

本地开发时如何快速验证 HTML 组件的可访问性

可访问性不是上线前才补的 checklist，而是从第一个 就该验证的事。Chrome DevTools 的 Lighthouse 和 Accessibility 面板能当场暴露硬伤。

• 打开 Elements 面板，右键组件 → Inspect Accessibility Properties，确认 role、name、state 是否完整（例如开关控件必须有 aria-checked）
• 用键盘 Tab 导航，观察焦点是否落到预期元素、是否有可见焦点环、是否跳过不可交互内容
• 禁用 CSS 后（DevTools → Command Menu → Disable styles），检查语义结构是否仍清晰（

  不能靠 font-size 区分）

• 别依赖 color contrast 工具插件——它们常忽略 background-image 或半透明叠加，用 DevTools 的 Color Picker 点击取色更准

最常被跳过的环节是「动态属性同步」：比如一个 HTML 组件根据 props 切换 data-status，但没同步更新 aria-live 或 tabindex。这类问题既不在 jsdom 里暴露，也不在 Lighthouse 报告里体现，只能靠 Playwright 在真实浏览器中触发状态变更后手动断言 DOM 快照。

以上就是《HTML组件测试方法详解》的详细内容，更多关于的资料请关注golang学习网公众号！