HTML组件测试实为HTML+CSS+JS构成的可复用UI单元测试，需用Playwright通过getByRole定位、断言状态变化与真实交互反馈，并在真实浏览器中验证动态属性同步与可访问性，而非仅测静态标签。
HTML 本身没有“组件”概念，所谓“HTML 组件测试”，实际测的是由 HTML + CSS + JS 构成的可复用 UI 单元（比如自定义按钮、卡片、表单控件），不是纯静态标签。 直接拿 <div class="btn"> 去测，不绑定行为、不验证渲染逻辑、不覆盖交互路径，等于没测。
怎么用 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，对视觉相关逻辑完全无感。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 它会把
offsetHeight === 0当成正常，哪怕元素被display: none或父容器溢出隐藏 -
focus()调用不会真正激活:focus样式，也无法验证键盘导航流程 - 异步加载的图片、字体、Web Worker 不会被模拟，
img.naturalWidth恒为 0 - 适合测「数据到 HTML 字符串」的纯渲染逻辑（如 React/Vue 的 snapshot），不适合测「HTML 到用户可见行为」
本地开发时如何快速验证 HTML 组件的可访问性
可访问性不是上线前才补的 checklist，而是从第一个 <button> 就该验证的事。Chrome DevTools 的 Lighthouse 和 Accessibility 面板能当场暴露硬伤。
立即学习“前端免费学习笔记（深入）”；
- 打开 Elements 面板，右键组件 →
Inspect Accessibility Properties，确认role、name、state是否完整（例如开关控件必须有aria-checked） - 用键盘 Tab 导航，观察焦点是否落到预期元素、是否有可见焦点环、是否跳过不可交互内容
- 禁用 CSS 后（DevTools → Command Menu →
Disable styles），检查语义结构是否仍清晰（<h2>不能靠 font-size 区分） - 别依赖 color contrast 工具插件——它们常忽略 background-image 或半透明叠加，用 DevTools 的 Color Picker 点击取色更准
最常被跳过的环节是「动态属性同步」：比如一个 HTML 组件根据 props 切换 data-status，但没同步更新 aria-live 或 tabindex。这类问题既不在 jsdom 里暴露，也不在 Lighthouse 报告里体现，只能靠 Playwright 在真实浏览器中触发状态变更后手动断言 DOM 快照。
