可测试的ui组件单元库核心在于模板生成的dom具备可定位、可断言、可交互的确定性行为：按钮需带role和aria-label或明确文本，禁用态须同步设置disabled属性与aria-disabled，优先使用getbyrole等语义查询，辅以data-testid兜底；jsdom仅适合纯html字符串一致性测试，playwright才能真实验证交互、焦点、可访问性及视觉反馈。

HTML 模板本身不带测试能力，所谓“可测试的 UI 组件单元库”，核心在于让模板产出的 DOM 具备可定位、可断言、可交互的确定性行为——不是模板语法有多漂亮，而是它生成的按钮能被 getByRole 找到，禁用态能被 toBeDisabled 验证，点击后状态变化能被真实观测。

怎么让 templ / Mustache / HTML 模板输出可测的 DOM 结构

模板只是字符串生成器，它不关心语义或可访问性。你必须在模板里主动注入测试必需的信号：

• 每个交互元素（button、input、select）必须带 role 和 aria-label 或明确的文本内容，否则 getByRole('button', { name: '保存' }) 会失败
• 禁用态不能只靠 class="disabled"，得同步写 aria-disabled="true" 和原生 disabled 属性（两者都写，兼容不同测试工具）
• 避免用纯 class 名定位（如 .btn-primary），测试时优先走语义路径；但可在模板里加 data-testid="save-button" 作为兜底（仅限开发/测试环境）
• 如果用 templ，直接在组件调用处传入测试所需属性：MyButton(text: "提交", disabled: true, testid: "submit-btn")，再在模板里展开为对应 HTML

为什么用 Jest + jsdom 测 templ/Mustache 模板容易漏逻辑

jsdom 不执行 CSS、不触发真实事件、不支持 IntersectionObserver，对模板类组件尤其危险：

使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件

如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Andr​​oid友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Andr​​oid应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更

下载

• 模板渲染出 display: none 的元素，jsdom 仍认为它“存在”且 offsetHeight > 0，但真实浏览器里它不可见也不可交互
• 键盘焦点流程（Tab → Enter → Shift+Tab）完全模拟不了，focus() 调用不会激活 :focus 样式，也无法验证 aria-activedescendant
• 异步加载的图标字体、SVG sprite、甚至 img 的 naturalWidth 在 jsdom 中恒为 0，导致基于尺寸的条件渲染逻辑永远走错分支
• 适合场景：只测“数据 → HTML 字符串”的纯输出一致性（比如比对 htmldiff），不适合测“用户点击后弹窗是否出现”这类行为

Playwright 是目前最靠谱的 HTML 模板组件测试方案

它跑在真实 Chromium/Firefox 上，能验证视觉反馈、焦点管理、动态属性同步和可访问性链路：

• 定位必须用语义方式：page.getByRole('button', { name: '删除' })，而不是 page.locator('.c-delete-btn') —— 后者一改 class 就崩
• 验证状态要等真实渲染：await expect(button).toBeDisabled()，它会检查 disabled 属性、aria-disabled 值、CSS pointer-events 三者是否一致
• 点击后必须等副作用发生：await button.click(); await expect(page.getByText('删除成功')).toBeVisible();，不能省略 await
• 遇到 Shadow DOM（比如封装了 Web Component 的模板）要显式进入：await page.locator('my-modal').shadowRoot().getByRole('dialog')

本地开发时快速验证模板组件的可访问性

别等上线才查，从第一个 button 就该验证：

• Chrome DevTools → Elements 面板右键组件 → Inspect Accessibility Properties，确认 role、name、aria-checked（开关）、aria-expanded（折叠面板）是否齐全
• 关掉鼠标，纯用 Tab 键导航：焦点是否落到预期元素？有没有可见焦点环？是否跳过 div 类容器？
• DevTools Command Menu（Ctrl+Shift+P）→ 输入 Disable styles，看结构是否仍语义清晰（h2 不能靠 font-size 区分层级）
• 禁用 JavaScript 后刷新页面：关键操作是否退化为可用的原生表单提交？这是可访问性的底线

真正难的不是写模板，而是让模板产出的每个字符都承担语义责任——class 名冲突、缺少 aria 属性、禁用态只改样式不改属性，这些细节在 Playwright 里会立刻暴露，在 jsdom 里却安静地假装正常。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！