react-testing-library：如何正确验证组件文本截断效果

现有实现 #

当前已实现支持基础截断能力的Label组件，代码如下：

import "./styles.css";
export default function Label(props) {
  const className = props.truncate ? "truncate" : "";
  return <label className={className}>{props.children}</label>;
}

配套截断样式定义：

.truncate {
  display: inline-block;
  overflow: hidden;
  white-space: pre;
  text-overflow: ellipsis;
  display: inline-flex;
  min-width: 0;
  max-width: 100%;
}

可通过运行示例直观查看组件及truncate属性的运行效果。

测试问题 #

使用react-testing-library编写测试用例时，尝试断言开启截断后文本末尾内容不可见，初始测试代码如下：

const longText = 'START Lorem ipsum dolor sit amet, consectetur adipiscing elit. In ac commodo massa END';
describe('Label', () => {
  it('displays long text', () => {
    render(<Label>{longText}</Label>);
    expect(screen.getByText(/^START/)).toBeInTheDocument(); // 用例通过
    expect(screen.getByText(/END$/)).toBeInTheDocument(); // 用例通过
  });
  it('displays long text with truncation', () => {
    render(<Label truncate={true}>{longText}</Label>);
    expect(screen.getByText(/^START/)).toBeInTheDocument(); // 用例通过
    expect(screen.queryByText(/END$/)).not.toBeVisible(); // 用例失败
  });
});

用例失败报错信息：

Received element is visible:
    <label class="truncate" />

团队不认可通过判断类名存在的测试方案，认为依赖类名这类实现细节属于不佳实践，需要符合最佳实践的截断效果断言方案。

问题根因 #

单元测试运行在jsdom环境中，jsdom作为Node端的DOM模拟实现，不具备浏览器的布局计算与渲染能力，无法识别overflow: hidden + text-overflow: ellipsis带来的文本裁剪效果。
toBeVisible()断言仅能识别显式隐藏场景：

• 元素设置display: none
• 元素设置visibility: hidden
• 元素携带hidden属性
• 元素祖先节点存在上述隐藏属性
  它无法判断溢出容器的文本是否被裁剪不可见，这是初始用例失败的核心原因。

最佳实践方案 #

单元测试不需要100%还原浏览器的渲染裁剪逻辑，这部分属于端到端测试的覆盖范围，单元测试层面只需要验证截断逻辑的行为契约即可，同时避免耦合类名等实现细节。

方案1：断言截断核心样式（单元测试推荐） #

不需要判断是否存在truncate类名，直接断言元素应用了截断所需的核心样式规则，属于行为验证而非实现细节验证：

it('applies truncation behavior when truncate prop is enabled', () => {
  render(<Label truncate={true}>{longText}</Label>);
  const labelEl = screen.getByText(/^START/);
  // 断言截断必备样式，与类名、具体实现解耦
  expect(labelEl).toHaveStyle(`
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: pre;
    max-width: 100%;
  `);
  // 验证完整文本已挂载到DOM（满足无障碍要求，截断仅为视觉效果，完整文本才能被屏幕阅读器识别）
  expect(labelEl).toHaveTextContent(longText);
});

文本截断本质是成熟CSS规则实现的视觉效果，只要元素正确应用了浏览器兼容的截断样式，截断行为就是确定可预期的，浏览器本身对CSS截断的实现不需要在单元测试中重复验证。

方案2：真实视觉裁剪验证（端到端测试覆盖） #

如果测试要求必须验证末尾文本确实视觉不可见，这部分属于端到端测试的范畴，需要使用Cypress、Playwright这类真实启动浏览器运行的测试框架，在真实渲染环境下断言：

// Playwright 示例
test('truncated label hides end content visually', async ({ page }) => {
  await page.goto('/component-demo-page');
  const endText = page.locator('text=END');
  await expect(endText).not.toBeInViewport();
});

不推荐的做法 #

不建议在jsdom中手动mock元素的offsetWidth、scrollWidth等尺寸属性模拟溢出场景，这类方案本质是手动构造了溢出的前置条件，相当于预先假设截断会生效，测试可信度极低，且维护成本很高。

内容的提问来源于stack exchange，提问作者Jonathan.Brink