html组件测试实为html+css+js构成的可复用ui单元测试，需用playwright通过getbyrole定位、断言状态变化与真实交互反馈，并在真实浏览器中验证动态属性同步与可访问性，而非仅测静态标签。
HTML 本身没有“组件”概念，所谓“HTML 组件测试”，实际测的是由 HTML + CSS + JS 构成的可复用 UI 单元（比如自定义按钮、卡片、表单控件），不是纯静态标签。 直接拿 <div class="btn"> 去测，不绑定行为、不验证渲染逻辑、不覆盖交互路径，等于没测。
<h3>怎么用 Playwright 断言一个 HTML 按钮是否渲染正确</h3>
<p>Playwright 是目前最贴近真实用户视角的轻量级选择，比 Selenium 启动快、API 更稳，适合验证 DOM 结构、文本、属性、状态变化。</p>
<ul>
<li>必须先确认按钮有 <code>name 或 aria-label —— 否则自动化工具无法可靠定位，getByRole('button', { name: '提交' }) 比 querySelector('.submit-btn') 更健壮
await expect(button).toBeDisabled()，而不是只看有没有 disabled 属性——有些组件用 class="disabled" 模拟，得结合 CSS 类或 aria-disabled="true"
await button.click() 就结束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，而是从第一个 <button></button> 就该验证的事。Chrome DevTools 的 Lighthouse 和 Accessibility 面板能当场暴露硬伤。
- 打开 Elements 面板，右键组件 →
Inspect Accessibility Properties，确认role、name、state是否完整（例如开关控件必须有aria-checked） - 用键盘 Tab 导航，观察焦点是否落到预期元素、是否有可见焦点环、是否跳过不可交互内容
- 禁用 CSS 后（DevTools → Command Menu →
Disable styles），检查语义结构是否仍清晰（<h2></h2>不能靠 font-size 区分） - 别依赖 color contrast 工具插件——它们常忽略 background-image 或半透明叠加，用 DevTools 的 Color Picker 点击取色更准
最常被跳过的环节是「动态属性同步」：比如一个 HTML 组件根据 props 切换 data-status，但没同步更新 aria-live 或 tabindex。这类问题既不在 jsdom 里暴露，也不在 Lighthouse 报告里体现，只能靠 Playwright 在真实浏览器中触发状态变更后手动断言 DOM 快照。
