Testing Library如何合规访问表格内节点避免ESLint报错

testing-library/no-node-access规则的核心设计逻辑是：测试代码应当尽可能模拟真实用户的感知路径，避免直接依赖DOM结构、原生节点方法查询元素，减少DOM结构微调导致的测试无效报错。

针对表格内容校验场景，推荐使用within API限定查询范围，配合语义化角色查询实现，完全不需要使用querySelector这类原生DOM访问方法。

基础实现（不依赖列位置，鲁棒性最强） #

绝大多数场景下你不需要关心内容在第几列，只需要校验内容是否正确渲染即可，实现代码如下：

import { within } from '@testing-library/dom';

const tableRows = screen.getAllByRole("row");
expect(tableRows).toHaveLength(2); // 表头行 + 1条数据行

// 将数据行作为查询限定范围，所有查询只会在当前行内匹配
const dataRow = within(tableRows[1]);

// 直接匹配用户可见的文本内容，无需关心列顺序
expect(dataRow.getByText("Hello")).toBeInTheDocument();
expect(dataRow.getByText("3 days ago")).toBeInTheDocument();
expect(dataRow.getByText("Success")).toBeInTheDocument();
// 操作按钮优先按按钮角色+可访问名称匹配，比读取拼接文本更贴近用户真实感知
expect(dataRow.getByRole("button", { name: "Edit" })).toBeInTheDocument();
expect(dataRow.getByRole("button", { name: "Delete" })).toBeInTheDocument();

这种写法的优势：

• 完全符合Testing Library API规范，不会触发ESLint规则报错
• 不依赖nth-child这类位置选择器，后续如果调整列的展示顺序，只要内容不变测试就不会误报
• 按钮校验逻辑更合理：真实用户不会感知到两个按钮同属一个单元格、拼接文本是"EditDelete"，只会识别到两个独立的操作按钮，测试逻辑和实际使用场景一致

需校验列顺序场景的实现 #

如果你的测试需求明确要求校验内容的展示位置、列顺序符合预期，可以直接通过cell角色拿到当前行所有单元格，按顺序校验，同样不需要调用原生节点方法：

const dataRow = within(tableRows[1]);
// 所有td元素默认对应cell角色，返回顺序和DOM中列顺序完全一致
const cells = dataRow.getAllByRole("cell");

// 第1列是折叠展开图标，从第2列开始校验
expect(cells[1]).toHaveTextContent("Hello");
expect(cells[2]).toHaveTextContent("3 days ago");
expect(cells[3]).toHaveTextContent("Success");

// 操作列可继续用within限定范围校验按钮
const actionCell = within(cells[4]);
expect(actionCell.getByRole("button", { name: "Edit" })).toBeInTheDocument();
expect(actionCell.getByRole("button", { name: "Delete" })).toBeInTheDocument();

注意事项 #

• 不要为了过 lint 直接禁用testing-library/no-node-access规则，该规则本质是引导你写出稳定性更高、参考价值更强的测试用例
• 优先使用用户可感知的文本、角色、标签属性查询元素，只有确实需要校验位置顺序的场景，才使用同角色元素列表的索引访问

内容的提问来源于stack exchange，提问作者JK Gunnink