React 组件交互测试：利用 Playwright 结合 React 选择器实现针对并发渲染场景的端到端验证 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位好，欢迎来到今天的“React 并发渲染与 Playwright 挑战赛”现场。

我是你们的讲师，一个在代码世界里摸爬滚打多年，见过无数组件崩溃、见过无数用户因为加载转圈圈而怒摔手机的开发者。今天，我们不聊那些花里胡哨的 Hooks，也不聊 Redux 怎么配置，我们来聊点硬核的——并发渲染，以及如何用Playwright这个神器来验证它。

你可能会问：“老师，React 18 都出来多久了？并发渲染不就是那个 useTransition 和 Suspense 吗？我点点按钮不就行了？”

嘿，朋友，如果你真的这么想，那你准备好迎接你的第一个 Bug 了。并发渲染不是简单的“快”，它是一场关于“优先级”的舞蹈。当你点击一个按钮，React 可能会暂停当前的渲染，去处理一个更高优先级的任务，然后再回来。这种场景下，传统的 E2E（端到端）测试就像是拿着望远镜看显微镜，根本看不清。

所以，今天我们不讲虚的，直接上干货。我们将深入探讨如何利用 Playwright 结合 React 选择器，构建一套能精准捕捉并发场景下微秒级交互的测试套件。

准备好了吗？让我们把 React 的内部机制像剥洋葱一样剥开来看看。

第一部分：并发渲染的“恐怖”故事

首先，我们要搞清楚我们在跟谁打交道。在 React 18 之前，React 是个老实孩子。你喊一声“渲染”，它就把所有东西画出来，画完为止。不管你在渲染过程中按了多少次鼠标，它都不理你，直到画完。

但是，React 18 的父亲——Ferris（Dan Abramov）觉得这太慢了。于是，他给 React 18 吃了药，让它学会了并发。

并发渲染的核心思想是：打断与恢复。

想象一下，你在渲染一个包含 1000 条数据的表格。React 开始渲染，渲染到第 500 条的时候，你突然点击了一个“删除”按钮。在旧版 React 中，表格会卡住，直到渲染完 1000 条，然后才去响应你的删除请求。用户体验？就像是在跟一个傲娇的客服聊天。

但在并发模式下，React 听到“删除”的指令，会立即挂起当前的表格渲染，优先处理删除操作，渲染完删除后的结果后，再回来继续渲染那剩下的 500 条数据。

这就是并发渲染的“恐怖”之处，也是测试的难点。因为 DOM 的变化不再是线性的，它是跳跃的、中断的。

第二部分：Playwright 与 React 选择器的联姻

以前我们怎么测？我们用 CSS 选择器。

document.querySelector('.search-input')，这行代码在 React 渲染前执行，可能返回 null。等 React 渲染完了，它才有值。这就像你在等披萨，披萨还没来，你就问老板“我的披萨好了吗？”老板说“还没”。

在并发场景下，DOM 的变化更频繁。React 可能渲染了一半，DOM 被清空了，又重新渲染了一半。这时候，CSS 选择器就像个瞎子，它只看脸（DOM 结构），不看心（React 的状态）。

这时候，Playwright 的 React 选择器 就闪亮登场了。

Playwright 官方提供了一个插件，它可以直接跟 React 的内部数据对话。它不需要等待 DOM 生成，它直接在 React 的 Fiber 树中查找组件。这就像你直接跟披萨店的老板说：“嘿，帮我查一下，那个叫 ‘loading’ 的披萨做好了吗？”老板直接从后厨喊出来：“做好了！”

这不仅仅是快，这是精准。

第三部分：核心工具箱——React 选择器 API

在进入并发测试之前，我们需要熟悉一下 Playwright 的 React 选择器全家桶。它们就像是一把把瑞士军刀。

getByRole：这是无障碍性之王。它不关心 DOM 结构长什么样，只关心这个元素在屏幕上扮演什么角色。比如“搜索框”、“按钮”、“列表项”。在并发渲染中，这是最稳定的锚点。
```
// 伪代码示例
const searchInput = await page.getByRole('searchbox', { name: 'Search items' });
```
getByText：这是文本匹配狂魔。当你找不到 Role 的时候，它就靠文本过日子。但在并发渲染中，文本可能会闪烁，所以慎用。
getByTestId：这是老朋友。虽然 React 社区现在不太推荐过度使用它，但在并发测试中，它是最诚实的。如果你给组件加了个 data-testid="user-list"，Playwright 就算 React 把 DOM 搞得稀巴烂，它也能找到这个挂载点。
getByDataTestid：注意，这是 Playwright 插件提供的功能。它允许你通过 React 组件内部的 data-testid 属性来查找元素。

第四部分：实战演练——构建一个“并发杀手”场景

为了演示，我们得有一个场景。我们来写一个“无限滚动搜索列表”。

场景是这样的：用户在输入框输入关键词，React 会去后台请求数据。因为数据量大，我们开启 useTransition 来处理搜索，这样即使用户连续打字，输入框也不会卡顿。同时，列表项是异步加载的，我们用 Suspense 来包裹。

这个场景包含了并发渲染的所有要素：异步操作、优先级切换、状态更新。

1. 组件代码

我们先看看这个组件长什么样。

// SearchComponent.jsx
import React, { useState, useTransition, useDeferredValue, Suspense } from 'react';
import SearchResults from './SearchResults';

const SearchComponent = () => {
  const [query, setQuery] = useState('');
  const [isPending, startTransition] = useTransition();
  const deferredQuery = useDeferredValue(query);

  const handleChange = (e) => {
    const value = e.target.value;
    setQuery(value);

    // 核心并发逻辑：将非紧急更新放入 transition 中
    startTransition(() => {
      // 这里的 fetchResults 会被标记为低优先级
      fetchResults(value); 
    });
  };

  return (
    <div>
      <input
        type="text"
        placeholder="Search..."
        value={query}
        onChange={handleChange}
        disabled={isPending}
      />
      {isPending && <div className="loading-indicator">Updating results...</div>}

      <Suspense fallback={<div>Loading more data...</div>}>
        <SearchResults query={deferredQuery} />
      </Suspense>
    </div>
  );
};

export default SearchComponent;

2. 传统测试的痛点

如果我们用传统的 Playwright 测试（假设没有 React 选择器插件）：

// 传统测试（伪代码）
test('search works', async ({ page }) => {
  await page.goto('http://localhost:3000');

  // 等待输入框出现
  await page.waitForSelector('input[type="text"]');

  // 输入文本
  await page.fill('input[type="text"]', 'React');

  // 等待结果出现
  await page.waitForSelector('.result-item');

  // 断言
  expect(await page.textContent('.result-item')).toContain('React');
});

问题在哪？
当用户快速输入“React”的时候，React 可能正在处理“Re”的更新，然后暂停去处理“ac”的更新。在这个过程中，.result-item 这个 DOM 元素可能存在，也可能不存在，或者被清空了。传统的 waitForSelector 往往会失效，或者因为等待时间过长而导致测试变慢。

第五部分：并发场景下的端到端验证策略

现在，我们引入 React 选择器 和 并发控制。

策略一：利用 `getByRole` 进行无障碍性锚定

因为 getByRole 依赖于 React 的语义化属性，而不是 DOM 结构，所以在 React 重新渲染 Fiber 树的时候，React 选择器依然能找到它。只要 React 还活着，输入框就在那里。

策略二：利用 `waitFor` 模拟时间与状态

Playwright 的 waitFor 方法非常强大。在并发场景中，我们不仅要等元素出现，还要等 React 的状态稳定下来。

const { test, expect } = require('@playwright/test');

test('concurrent search should not block UI', async ({ page }) => {
  await page.goto('http://localhost:3000');

  // 使用 React 选择器定位输入框
  const searchInput = await page.getByRole('searchbox', { name: /search/i });

  // 开始快速输入，模拟并发更新
  for (const char of ['R', 'e', 'a', 'c', 't']) {
    // 这里有个技巧：在输入前，我们检查一下 loading 状态
    // 因为 React 在处理输入时可能会更新 loading 状态
    await searchInput.pressSequentially(char);

    // 关键点：等待 Suspense 加载完成
    // React 选择器会自动处理 Suspense 的 fallback 状态
    await expect(page.getByRole('status', { name: /loading/i })).not.toBeVisible();
  }

  // 验证最终结果
  const results = page.getByRole('listitem');
  await expect(results).toHaveCount(5); // 假设搜到了5个结果
});

这段代码展示了并发测试的核心：在状态不断变化的过程中，验证最终的状态。Playwright 的 expect 语句会自动处理重试，只要在超时时间内状态稳定了，测试就会通过。

第六部分：深入 `useTransition` 的测试

useTransition 是并发渲染中最难测试的部分。它涉及到“中断”和“优先级”。

我们要测试的是：当用户在搜索时，点击了一个“加载更多”的按钮，搜索框的输入应该不卡顿，而“加载更多”应该优先执行。

测试场景

用户开始输入搜索词。
React 开始处理搜索更新（低优先级）。
用户立即点击“加载更多”。
React 应该立即响应用户的点击，渲染“加载更多”的进度条。
React 应该在后台继续完成搜索更新。

代码示例

test('transition priority: clicking button should not wait for search', async ({ page }) => {
  await page.goto('http://localhost:3000');

  const searchInput = page.getByRole('searchbox', { name: /search/i });
  const loadMoreButton = page.getByRole('button', { name: /load more/i });
  const resultsArea = page.getByRole('list', { name: /results/i });

  // 1. 开始搜索
  await searchInput.fill('Test Query');

  // 等待搜索结果出现（这会触发 transition）
  await expect(resultsArea).toBeVisible();

  // 2. 在搜索过程中点击加载更多
  // 注意：我们这里不需要等待 searchInput 的 disabled 状态，
  // 因为在并发模式下，输入框通常不会因为 search 而被完全 disable，
  // 除非你特意设置了 disabled={isPending}。
  // 让我们假设组件逻辑是：输入框一直可用，但搜索是 defer 的。

  await loadMoreButton.click();

  // 3. 验证加载更多按钮的状态变化
  // React 选择器可以轻松捕捉到按钮从“加载更多”变为“加载中...”
  await expect(loadMoreButton).toHaveText(/loading/i);

  // 4. 验证输入框依然可用（这是并发测试的关键指标）
  await searchInput.press('Backspace');
  await expect(searchInput).toHaveValue('Test Quer'); // 搜索还在后台跑，但输入框没卡死

  // 5. 验证最终结果
  await expect(resultsArea).toContainText('Test Query');
});

看，这段代码非常优雅。我们不需要去模拟 React 的 Fiber 栈，我们只需要模拟用户的真实行为。Playwright 会自动帮我们处理底层的同步问题。

第七部分：模拟并发状态

有时候，我们测试的组件需要一些特定的状态才能触发并发行为，比如“网络延迟”。在 E2E 测试中，我们很难控制网络速度。

Playwright 提供了 route API，我们可以用它来拦截 API 请求，并人为地制造延迟。

test('suspense handling with network delay', async ({ page }) => {
  await page.route('**/api/search', route => {
    // 模拟 1 秒的网络延迟
    setTimeout(() => {
      route.fulfill({
        status: 200,
        contentType: 'application/json',
        body: JSON.stringify({ data: ['Result 1', 'Result 2'] })
      });
    }, 1000);
  });

  await page.goto('http://localhost:3000');

  const searchInput = page.getByRole('searchbox', { name: /search/i });
  const resultsArea = page.getByRole('list', { name: /results/i });

  await searchInput.fill('React');

  // 此时，Suspense 会显示 loading 状态
  await expect(page.getByText(/loading more data/i)).toBeVisible();

  // 等待 1 秒后，数据加载完成
  await page.waitForTimeout(1100);

  // React 选择器会自动等待 Suspense 的内容更新
  await expect(resultsArea).toBeVisible();
});

这里，route 就是我们测试并发渲染的“上帝之手”。我们控制了时间的流速，从而控制了 React 的渲染时机。

第八部分：调试并发测试的艺术

并发测试最怕什么？最怕测试挂了，你不知道为什么。

Playwright 的 Inspector 是一个神器。当你运行测试时，勾选上“Debug mode”，Playwright 会打开一个侧边栏。

Highlight Elements：你可以看到 Playwright 使用 React 选择器定位到的元素。即使元素在 DOM 树中消失了，只要它还在 React 的 Fiber 树里，Inspector 就能高亮它。这是调试 React 选择器的利器。
Step through：你可以单步执行测试。你可以看到在 pressSequentially 的循环中，React 每次更新后的状态。

常见陷阱：

Too Much Waiting：不要用 page.waitForTimeout(5000) 来等待结果。并发渲染的核心是“快”，你用 5 秒等待，就失去了测试并发性能的意义。
Race Conditions：确保你的测试顺序是逻辑正确的。比如，不要在点击按钮之前就断言按钮状态已改变。
Flaky Tests：并发测试很容易变得不稳定。如果网络稍微慢一点，isPending 的状态可能就会变。使用 expect(...).not.toBeVisible() 或者 expect(...).toBeVisible() 的组合来覆盖所有状态。

第九部分：进阶技巧——`waitForFunction` 与 React 状态

有时候，DOM 没变，但 React 的状态变了。比如，你有一个状态 isLoading，它变成了 true，但 UI 上并没有出现一个新的 Loading 组件，因为 Loading 组件一直都在。

这时候，CSS 选择器帮不了你，React 选择器也帮不了你（因为没 DOM 变化）。你需要用 waitForFunction。

test('check internal state without DOM change', async ({ page }) => {
  await page.goto('http://localhost:3000');

  // 我们需要注入一段 JS 到浏览器中，去检查 React 组件的 state
  // 注意：这在 E2E 测试中比较少见，通常用于调试，
  // 但在极其复杂的并发场景下，这是一个终极武器。

  await page.waitForFunction(() => {
    // 获取 React 根组件实例
    const rootElement = document.getElementById('root');
    // 这里的逻辑取决于你的组件如何暴露状态
    // 比如你可能在 window 对象上挂了一个全局变量
    return window.appState && window.appState.isTransitioning;
  });
});

但是，这通常不是最佳实践。更好的做法是让组件在状态改变时触发一个 DOM 变化，或者使用 React DevTools 的 Profiler 来分析。

第十部分：综合案例——构建一个高并发仪表盘

让我们把前面所有的知识点串联起来。假设我们有一个仪表盘，包含：

实时图表：每秒更新一次（高优先级）。
用户列表：随用户滚动更新（低优先级）。
搜索框：输入时筛选列表（中优先级）。

当用户在搜索框输入时，图表应该继续流畅更新，列表应该延迟更新。

测试代码结构

test('dashboard concurrency: chart updates while searching', async ({ page }) => {
  await page.goto('http://localhost:3000');

  // 1. 获取元素
  const chartArea = page.getByRole('graphics-document', { name: /live chart/i });
  const userList = page.getByRole('list', { name: /users/i });
  const searchInput = page.getByRole('searchbox', { name: /filter users/i });

  // 2. 监听图表更新（假设图表有一个 timestamp 标签）
  const chartUpdates = page.waitForFunction(() => {
    const timestamp = document.querySelector('.chart-timestamp');
    return timestamp && timestamp.textContent !== 'Just now';
  });

  // 3. 用户开始搜索
  await searchInput.fill('Alice');

  // 4. 验证图表没有卡顿
  // 如果图表卡顿了，waitForFunction 会一直等不到更新，导致超时
  await expect(chartUpdates).not.toHaveTimeout(); // 或者直接 await chartUpdates

  // 5. 验证用户列表有延迟更新（这是 DeferredValue 的效果）
  // 我们先断言列表是空的（旧状态）
  await expect(userList).not.toBeVisible();

  // 等待一小会儿（或者等待 React transition 完成）
  await page.waitForTimeout(100); 

  // 断言列表出现了
  await expect(userList).toBeVisible();
});

这段代码非常精彩。它验证了高优先级任务（图表）没有被阻塞，同时也验证了低优先级任务（用户列表）确实被延迟了。这就是并发渲染测试的精髓所在。

第十一部分：总结与避坑指南

好了，朋友们，今天的讲座接近尾声。

我们今天探讨了 React 并发渲染的复杂性，以及如何利用 Playwright 的 React 选择器来驾驭这种复杂性。

核心要点回顾：

不要依赖 DOM 结构：并发渲染会打乱 DOM 结构。使用 getByRole 和 getByTestId。
关注状态流：测试的不仅仅是“点击”，而是“状态的变化过程”。
模拟时间：使用 page.route 来模拟网络延迟，从而控制 React 的渲染时机。
验证优先级：确保高优先级任务不阻塞低优先级任务。

最后，给大家几个避坑建议：

不要在测试中写死等待时间：除非你真的需要等待网络延迟，否则用 waitFor 和 expect 来代替 setTimeout。
善用 React 选择器插件：如果你还没装，赶紧去装。它能让你的测试代码更健壮，更符合 React 的设计哲学。
保持组件的纯粹性：如果你的组件太难测（比如状态藏在深处的 Context 里），考虑在测试环境中 mock 掉 Context，或者给组件加个 data-testid。

记住，测试并发渲染不是为了证明 React 能跑，而是为了证明在 React 跑的时候，你的应用依然能像瑞士手表一样精准、流畅。

祝大家在并发渲染的测试世界里玩得开心，代码少点 Bug，多点快乐！如果有任何问题，欢迎在评论区——哦不，欢迎在课后提问！

（完）