首页 > web前端 > js教程 > 正文

React Testing Library:测试异步状态更新与搜索过滤的正确姿势

DDD
发布: 2025-11-21 14:23:02
原创
665人浏览过

react testing library:测试异步状态更新与搜索过滤的正确姿势

在React Testing Library中测试包含异步操作(如数据获取和搜索过滤)的组件时,确保UI在状态更新后正确渲染是一个常见挑战。本文将深入探讨如何利用waitFor和findBy*等异步工具,解决测试中因异步状态更新导致UI未及时反映最新DOM状态的问题,从而编写出健壮可靠的测试代码。

理解异步组件测试的挑战

在React应用中,许多组件都依赖于异步操作,例如从API获取数据或根据用户输入进行数据过滤。当这些异步操作完成后,组件的状态会更新,进而触发UI的重新渲染。在测试环境中,如果测试代码在UI完成重新渲染之前就进行断言,就可能导致测试失败,因为它检查的是过时的DOM状态。

以一个待办事项列表组件为例,它包含以下特性:

  1. 初始数据加载:通过useEffect在组件挂载时从API获取待办事项列表。
  2. 搜索过滤:用户在输入框中输入关键词时,组件会根据关键词过滤待办事项,并更新显示的列表。

当尝试测试搜索过滤功能时,常见的问题是:即使fireEvent.change触发了输入框值的改变,并更新了组件内部的search状态,但由于React的异步更新机制,useEffect中的过滤逻辑和随后的UI重新渲染可能尚未完成,导致测试无法获取到正确的过滤结果。

示例组件代码分析

让我们审视一个典型的待办事项组件,它展示了上述异步行为:

import React, { useState, useEffect } from 'react';

interface TodoItem {
  userId: number;
  id: number;
  title: string;
  completed: boolean;
}

interface TodosState {
  all: TodoItem[];
  searched: TodoItem[] | null;
}

const Home: React.FC = () => {
  const [todos, setTodos] = useState<TodosState>({ all: [], searched: null });
  const [search, setSearch] = useState<string>('');

  // 1. 初始数据获取
  useEffect(() => {
    fetch("some url todos") // 模拟API调用
      .then((response) => response.json())
      .then((response: TodoItem[]) => {
        setTodos((prevTodos) => ({ ...prevTodos, all: response }));
      })
      .catch((e) => console.error(e));
  }, []);

  // 2. 根据搜索词过滤待办事项
  useEffect(() => {
    setTodos((prevTodos) => ({
      ...prevTodos,
      searched: search
        ? prevTodos.all.filter((item) =>
            item.title.toLowerCase().includes(search.toLowerCase())
          )
        : null,
    }));
  }, [search, todos.all]); // 依赖todos.all确保在all更新后也能正确过滤

  const handleOnChangeInput = (e: React.ChangeEvent<HTMLInputElement>) => {
    setSearch(e.target.value);
  };

  const displayedTodos = todos.searched && todos.searched.length > 0
    ? todos.searched
    : todos.all;

  return (
    <div>
      <div className="search-container">
        <input
          className="search"
          value={search}
          onChange={handleOnChangeInput}
          placeholder="Search todo..."
          data-testid="search"
          type="text"
        />
      </div>
      <div className="todos" data-testid="todos">
        {displayedTodos.map(({ title, id }) => (
          <p key={id} data-testid="todo">
            {title}
          </p>
        ))}
      </div>
    </div>
  );
};

export default Home;
登录后复制

编写有问题的测试代码

最初,测试人员可能会尝试编写如下的测试代码来验证搜索功能:

import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import { MemoryRouter } from 'react-router-dom';
import Home from './Home'; // 假设组件路径

const mockResponse = [
  { userId: 1, id: 1, title: "Todo S", completed: false },
  { userId: 1, id: 2, title: "Todo A", completed: true },
];

describe('Home Component', () => {
  beforeEach(() => {
    // 模拟全局的fetch API
    jest.spyOn(global, "fetch" as any).mockResolvedValue({
      json: () => Promise.resolve(mockResponse), // 确保返回Promise
    });
  });

  afterEach(() => {
    jest.restoreAllMocks();
  });

  it("should filter todos based on search input", async () => {
    render(
      <MemoryRouter>
        <Home />
      </MemoryRouter>
    );

    // 1. 交互:改变搜索输入框的值
    const searchInput = screen.getByTestId("search");
    fireEvent.change(searchInput, {
      target: { value: "A" },
    });

    // 2. 断言:查找过滤后的待办事项
    // 期望这里能立即找到一个待办事项 "Todo A"
    const todos = await screen.findAllByTestId("todo"); // 可能会在这里失败
    expect(todos).toHaveLength(1);
    expect(screen.getByText("Todo A")).toBeInTheDocument();
    expect(screen.queryByText("Todo S")).not.toBeInTheDocument();
  });
});
登录后复制

这个测试可能会失败,原因在于:

  1. 初始数据加载:render之后,第一个useEffect会异步调用fetch。fireEvent.change可能在fetch完成并更新todos.all之前就执行了。
  2. 搜索状态更新与UI渲染:fireEvent.change会更新search状态,这会触发第二个useEffect来过滤todos.all。然而,从search状态改变到todos.searched状态更新,再到UI重新渲染以显示过滤后的结果,这整个过程是异步的。await screen.findAllByTestId("todo")可能在UI尚未完全更新到只显示“Todo A”的状态时就执行了,因此仍然看到了所有待办事项。

解决方案:利用 waitFor 和 findBy* 异步工具

@testing-library/react 提供了强大的异步工具来解决这些问题:

  • *`findBy查询**:这类查询(如findByText,findByRole,findAllByTestId等)在内部使用了waitFor`,它们会等待匹配的元素出现在DOM中,直到超时。
  • waitFor 工具函数:这是一个更通用的工具,允许你等待任何条件变为真。它会周期性地执行一个回调函数,直到该函数不抛出错误或超时。

为了确保测试的健壮性,我们需要在关键的异步操作之后,明确地等待UI更新。

落笔AI
落笔AI

AI写作,AI写网文、AI写长篇小说、短篇小说

落笔AI 41
查看详情 落笔AI

优化后的测试代码

以下是使用 waitFor 和 findBy* 优化后的测试代码:

import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import { MemoryRouter } from 'react-router-dom';
import Home from './Home';

const mockResponse = [
  { userId: 1, id: 1, title: "Todo S", completed: false },
  { userId: 1, id: 2, title: "Todo A", completed: true },
];

describe('Home Component', () => {
  beforeEach(() => {
    jest.spyOn(global, "fetch" as any).mockResolvedValue({
      json: () => Promise.resolve(mockResponse),
    });
  });

  afterEach(() => {
    jest.restoreAllMocks();
  });

  it("should filter todos based on search input correctly", async () => {
    render(
      <MemoryRouter>
        <Home />
      </MemoryRouter>
    );

    // 1. 等待初始数据加载完成并渲染到UI
    // 使用 findByText 等待一个在初始加载后才出现的元素
    await screen.findByText("Todo S"); // 确保 "Todo S" 在DOM中,表明fetch已完成

    // 2. 交互:改变搜索输入框的值
    const searchInput = screen.getByTestId("search");
    fireEvent.change(searchInput, {
      target: { value: "A" },
    });

    // 3. 等待UI根据搜索结果重新渲染
    // 使用 waitFor 来等待一个条件变为真:即DOM中只剩下过滤后的元素
    await waitFor(() => {
      const todos = screen.getAllByTestId("todo");
      expect(todos).toHaveLength(1); // 断言过滤后只剩一个待办事项
      expect(screen.getByText("Todo A")).toBeInTheDocument(); // 确保 "Todo A" 存在
      expect(screen.queryByText("Todo S")).not.toBeInTheDocument(); // 确保 "Todo S" 不存在
    });
  });
});
登录后复制

代码解释:

  1. await screen.findByText("Todo S");

    • 在render之后立即使用。findByText是一个异步查询,它会等待带有文本“Todo S”的元素出现在DOM中。由于“Todo S”是mockResponse中的一个初始待办事项,它的出现标志着useEffect中的fetch操作已经完成,并且组件已经使用获取到的数据进行了第一次渲染。这解决了在数据加载完成前就进行搜索的问题。
  2. fireEvent.change(searchInput, { target: { value: "A" } });

    • 触发搜索输入框的onChange事件,更新search状态。这会异步触发第二个useEffect,执行过滤逻辑,并最终导致UI重新渲染。
  3. await waitFor(() => { ... });

    • 这是解决问题的关键。在fireEvent.change之后,我们使用waitFor来等待一个特定的条件变为真。waitFor会周期性地执行其回调函数,直到回调函数不再抛出错误(即所有断言都通过)或达到默认超时时间(通常是1000ms)。
    • 在回调函数内部,我们放置了关于过滤结果的断言:
      • screen.getAllByTestId("todo"):获取所有待办事项。
      • expect(todos).toHaveLength(1):断言过滤后只剩一个待办事项。
      • expect(screen.getByText("Todo A")).toBeInTheDocument():确保“Todo A”是唯一显示的待办事项。
      • expect(screen.queryByText("Todo S")).not.toBeInTheDocument():确保“Todo S”已经被过滤掉,不再显示。queryByText用于查询可能不存在的元素,如果不存在则返回null,不会抛出错误。

通过这种方式,我们确保了测试在执行断言之前,组件已经完成了所有异步操作和UI的重新渲染,从而准确地反映了用户在搜索后的界面状态。

注意事项与最佳实践

  • 明确等待条件:避免使用空的waitFor回调(如await waitFor(() => {})),因为它只是等待时间,并不能保证特定的UI状态。始终在waitFor中包含具体的断言,使其等待有意义的条件。
  • *利用`findBy查询**:对于简单地等待某个元素出现的情况,findBy*查询通常比手动编写waitFor更简洁和语义化。例如,await screen.findByText("Loading...")`可以用来等待加载指示器消失。
  • 避免不必要的等待:过度使用waitFor或设置过长的超时时间会减慢测试速度。只在确实需要等待异步操作完成时使用。
  • 模拟API调用:始终使用jest.spyOn或msw等工具模拟网络请求,以确保测试的独立性和可预测性,避免实际的网络依赖。
  • 清理模拟:在afterEach中使用jest.restoreAllMocks()来清理spyOn,防止测试之间互相影响。
  • 理解act:react-testing-library的render和fireEvent内部通常会处理act包裹,但在更复杂的异步场景或自定义钩子测试中,可能需要手动使用act来确保所有React更新都被正确处理,避免控制台警告。

总结

在React Testing Library中测试异步组件是一个常见但可解决的问题。核心在于理解React的异步更新机制,并利用@testing-library/react提供的异步工具(如waitFor和findBy*查询)来确保测试在UI完成所有异步渲染后才进行断言。通过在关键时刻等待特定的UI状态,我们可以编写出既高效又准确的组件测试,从而提高应用的质量和稳定性。

以上就是React Testing Library:测试异步状态更新与搜索过滤的正确姿势的详细内容,更多请关注php中文网其它相关文章!

最佳 Windows 性能的顶级免费优化软件
最佳 Windows 性能的顶级免费优化软件

每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。

下载
来源:php中文网
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
最新问题
开源免费商场系统广告
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新 English
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习

Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号