HTML本身不需单元测试，真正要测的是JavaScript行为、DOM操作逻辑及组件在浏览器中的表现。
HTML 本身不做单元测试——你真正要测的是 JavaScript 行为、DOM 操作逻辑，以及组件在浏览器环境中的表现。 直接对 <div></div> 写单元测试没有意义，但如果你写了 renderHeader() 函数生成 HTML 字符串，或用 React/Vue 渲染一个按钮并绑定点击逻辑，那就必须测。
为什么不能直接测 HTML 标签？
HTML 是声明式标记，不包含可执行逻辑。所谓“HTML 单元测试”，实际是测三类东西：
- JS 函数是否正确生成/操作 HTML 字符串（比如
buildTableHtml(data)） - 前端框架组件（如 React 的
Header）是否按 props 渲染出预期 DOM 结构 - 事件处理函数（如
handleClick）触发后，DOM 是否更新、状态是否变更、API 是否调用
常见错误现象：有人把 index.html 丢进 unittest 或 pytest 里跑，报错 ImportError: No module named 'html' 或直接跳过——因为 Python 的 unittest 不解析 HTML 文件，它只找 .py 里的 TestCase 类。
用 Jest 测 React/Vue 组件的 DOM 输出
Jest + @testing-library/react 是目前最贴近“测 HTML 表现”的组合。它不关心你怎么实现，只验证最终用户看到什么。
立即学习“前端免费学习笔记（深入）”；
例如测一个 Button 组件：
import { render, screen } from '@testing-library/react';
import Button from './Button';
test('renders button with correct text', () => {
render(<Button label="Submit" />);
const btn = screen.getByRole('button', { name: /submit/i });
expect(btn).toBeInTheDocument();
expect(btn).toHaveTextContent('Submit');
});
关键点：
-
render()在虚拟 DOM 中挂载组件，不启动真实浏览器 -
screen.getByRole()比getByTestId更语义化，也更接近可访问性要求 - 不要断言
innerHTML—— 它脆弱、易受空格/注释/属性顺序影响；优先用getByRole、getByText、getByAltText - 若组件内有异步请求，需用
await waitFor(() => ...)等待 DOM 更新
用 Vitest 测纯函数生成的 HTML 字符串
如果你写的是无框架工具函数，比如从数据生成表格 HTML：
export function generateTableHtml(rows) {
return <table>${rows.map(r => <tr><td>${r.name}</td></tr>).join('')}</table>;
}
对应测试就很简单直接：
import { generateTableHtml } from './htmlUtils';
test('generates table with two rows', () => {
const html = generateTableHtml([{name: 'Alice'}, {name: 'Bob'}]);
expect(html).toContain('<table>');
expect(html).toContain('<tr><td>Alice</td></tr>');
expect(html).toContain('<tr><td>Bob</td></tr>');
});
注意：
- 别用正则去匹配整个 HTML 字符串——结构微调（比如加个 class）就会让测试失败
- 如果函数返回的是带引号的字符串（如
"<div class=\"btn\">OK</div>"），确保测试中也用双引号或转义一致 - 这种测试适合工具函数，不适合含副作用（如
document.getElementById）的代码——那得进浏览器环境跑
别在 Node 环境里 mock document 来测交互逻辑
有人用 jsdom 在 Node 里模拟 DOM，然后写：
global.document = jsdom.jsdom(`<button id="btn">Click</button>`);
document.getElementById('btn').addEventListener('click', handler);
document.getElementById('btn').click(); // 触发
这看似能跑通，但问题很多：
-
jsdom对 CSSOM、布局、事件冒泡、getBoundingClientRect等支持不全，和真实浏览器行为不一致 - 一旦涉及
focus()、scrollIntoView()、IntersectionObserver，测试就失效 - 维护成本高：每次浏览器更新 API，你的 mock 就可能漏掉新行为
真正需要测交互时，应升一级到端到端（E2E）工具，如 Playwright 或 Cypress，在真实 Chromium/Firefox 实例中运行。单元测试只负责“输入 → 输出”逻辑，不负责“渲染后用户能不能点”。
最常被忽略的一点：很多人把 HTML 单元测试当成“检查页面有没有少写一个 </div>”，其实那是 linter（如 eslint-plugin-html）或格式校验（prettier）该干的事。单元测试只管“这个按钮点了之后，数据变了没、跳转对不对、错误提示显没显示”。边界必须划清，否则测试既慢又脆。
