React 逻辑的可测试性：针对 React Hooks 的单体测试与渲染行为模拟的质量保障实践

主讲人： 某资深前端架构师（也就是我）
受众： 想要逃离“闭包地狱”和“测试屎山”的前端开发者们
时长： 漫长的周一午后

---

第一部分：引子——我们为什么在这里？

大家好，欢迎来到今天的讲座。我知道，当你的经理说“我们需要测试一下那个 useEffect”的时候，你的第一反应可能不是“太好了，这是提高代码质量的机会”，而是“我的头发又要掉光了”。

React Hooks 的出现，本意是让我们能把逻辑从组件中剥离出来，变成可复用的函数。这听起来很美好，就像“自由”一样。但现实是，一旦你开始写自定义 Hooks，你就掉进了一个名为“可测试性”的深坑。

我们今天要聊的不是“如何写一个测试用例”，而是“如何优雅地测试那些原本像黑魔法一样的 Hook”。

首先，我们要明确一个概念：测试 UI 是测试渲染，测试 Hook 是测试逻辑。 如果你想测试一个 Hook，你不需要关心它到底渲染了 <div> 还是 <canvas>，你只需要关心它计算出的状态对不对，副作用触发了没有。

准备好了吗？让我们开始这场“与 Bug 的博弈”。

---

第二部分：工具箱的选择——你手里的剑

在开始之前，我们要明确手里有什么牌。测试 React Hooks，主流有两个工具：

1. @testing-library/react：这是目前最流行的。它主要用来测试组件，但它也提供了一个 renderHook 辅助函数。它就像一个全自动的机器人，帮你创建组件、挂载、卸载。
2. jest-dom：这是 @testing-library 的好基友，它让你的断言（expect）变得更像人类的语言（例如 toBeInTheDocument() 而不是 toBeTruthy()）。

但是，机器人有时候太听话了。renderHook 会帮你处理所有的事情，包括渲染副作用。如果你想知道你的 Hook 在渲染时到底干了什么，机器人可能会把秘密藏起来。

所以，今天我们要讲的是“手动渲染”和“渲染行为模拟”。这就像是把机器人踢开，自己动手去观察这个 Hook 的行为。

---

第三部分：单体测试 Hooks 的核心——逻辑即契约

单体测试 Hook，本质上是在测试一个纯函数。这个函数接收输入（依赖项），输出输出（状态、回调函数）。

示例 1：最简单的状态管理

假设我们有一个 Hook，用来管理一个购物车的数量。

// useShoppingCart.js
export const useShoppingCart = () => {
  const [items, setItems] = React.useState(0);

  const addToCart = () => {
    setItems((prev) => prev + 1);
  };

  const removeFromCart = () => {
    setItems((prev) => Math.max(0, prev - 1));
  };

  return { items, addToCart, removeFromCart };
};

现在，我们要写测试。注意，我们不要渲染任何 DOM，我们只测试逻辑。

// useShoppingCart.test.js
import { renderHook } from '@testing-library/react';
import { useShoppingCart } from './useShoppingCart';

test('should increment item count', () => {
  // 1. 渲染 Hook
  const { result } = renderHook(() => useShoppingCart());

  // 2. 获取初始状态
  expect(result.current.items).toBe(0);

  // 3. 触发 action
  act(() => {
    result.current.addToCart();
  });

  // 4. 断言结果
  expect(result.current.items).toBe(1);
});

这段代码很简单对吧？这就是单体测试的精髓：隔离。我们不看浏览器，不看控制台，只看内存里的数据流。

---

第四部分：渲染行为模拟——当 Hook 涉及副作用

这是今天讲座的重头戏。很多 Hook 都有副作用，比如订阅数据、调用 API、或者注册事件监听器。这些副作用通常在 useEffect 里。

问题来了： 如果你用 renderHook，它会自动帮你处理 useEffect。你想测试“当数据加载时，UI 是否更新”，这个测试是写不出来的，因为 renderHook 根本不给你机会看 UI 更新，它直接帮你把副作用跑完了。

这时候，我们需要“模拟渲染行为”。

概念解析：模拟渲染行为

所谓模拟渲染行为，就是不使用 renderHook，而是手动创建一个组件来包装你的 Hook，然后渲染这个组件。

这样做的好处是：你可以完全控制组件的渲染过程，你可以捕获 Hook 内部调用的所有回调函数，你可以测试这些函数是在什么时候被调用的。

示例 2：带 API 调用的复杂 Hook

假设我们有一个 Hook，用于从 API 获取用户信息，并更新 UI。

// useUserProfile.js
export const useUserProfile = (userId) => {
  const [user, setUser] = React.useState(null);
  const [loading, setLoading] = React.useState(true);

  // 模拟 API 调用
  React.useEffect(() => {
    const fetchUser = async () => {
      setLoading(true);
      // 模拟网络延迟
      await new Promise((resolve) => setTimeout(resolve, 500));
      setUser({ id: userId, name: 'Test User' });
      setLoading(false);
    };

    fetchUser();
  }, [userId]);

  return { user, loading };
};

如果我们用 renderHook，测试会变成这样：

// 这种写法虽然简单，但无法测试 "loading 状态的变化过程"
test('should fetch user data', async () => {
  const { result } = renderHook(() => useUserProfile(1));

  await waitFor(() => expect(result.current.user).not.toBeNull());
});

这看起来没问题，但如果你的 API 调用失败了呢？或者你想测试“如果 userId 变了，是否重新请求”呢？

让我们用“渲染行为模拟”来重写这个测试。

// useUserProfile.test.js
import { render, screen, waitFor } from '@testing-library/react';
import { useUserProfile } from './useUserProfile';

// 1. 创建一个包装组件
const UserProfileWrapper = ({ userId }) => {
  const { user, loading } = useUserProfile(userId);

  // 我们可以在这里做一些渲染逻辑，或者什么都不做
  return (
    <div>
      {loading && <div>Loading...</div>}
      {user && <div data-testid="user-name">{user.name}</div>}
    </div>
  );
};

test('should render user name after loading', async () => {
  // 2. 渲染包装组件
  render(<UserProfileWrapper userId={1} />);

  // 3. 断言初始状态
  expect(screen.getByText('Loading...')).toBeInTheDocument();

  // 4. 等待异步操作完成
  await waitFor(() => {
    expect(screen.getByTestId('user-name')).toHaveTextContent('Test User');
  });
});

这有什么区别？
区别在于，我们不仅验证了结果，我们还验证了渲染过程。我们看到它先渲染了 Loading...，然后才渲染了用户名。这就是“行为模拟”。

---

第五部分：深入模拟——Mocking 依赖项

很多时候，Hook 依赖于外部服务（比如 Redux store，或者一个自定义的 Context）。在单元测试中，我们不需要真的连接到数据库，我们需要的是Mock（模拟）。

场景：依赖 Context 的 Hook

假设我们有一个 Hook，它从 Context 中获取当前的 Theme。

// useTheme.js
export const useTheme = () => {
  return React.useContext(ThemeContext);
};

错误的做法：
在测试里去 Provider 包裹组件，这叫集成测试，不叫单体测试。

正确的做法：Mock Context

// useTheme.test.js
import { renderHook, act } from '@testing-library/react';
import { useTheme } from './useTheme';

// 1. 创建一个假的 Context
const MockThemeContext = React.createContext('dark');

// 2. 创建一个包装 Hook 的组件
const ThemeWrapper = ({ theme }) => {
  return (
    <MockThemeContext.Provider value={theme}>
      {/* 这里其实不需要渲染任何东西，只要 Provider 存在即可 */}
    </MockThemeContext.Provider>
  );
};

test('should return context theme', () => {
  // 3. 手动渲染
  const wrapper = ({ theme }) => (
    <MockThemeContext.Provider value={theme}>
      <div />
    </MockThemeContext.Provider>
  );

  const { result } = renderHook(() => useTheme(), { wrapper });

  // 4. 断言
  expect(result.current).toBe('dark');
});

技巧： 我们通过 wrapper prop，把 Context 的值注入进去。这就是“依赖注入”的思想，只不过注入的是测试数据。

---

第六部分：测试回调函数的调用顺序

这是“渲染行为模拟”的终极奥义。有时候，Hook 里的逻辑非常复杂，它可能在一个循环里调用了三次 onSuccess 回调。我们不仅要测试回调被调用了，还要测试它被调用了几次，以及顺序。

示例 3：验证副作用触发顺序

假设我们有一个 Hook，用于处理表单提交。它需要先验证，然后提交，最后重置表单。

// useFormHandler.js
export const useFormHandler = (onSubmit) => {
  const [status, setStatus] = React.useState('idle');

  const handleSubmit = (data) => {
    setStatus('validating');
    // 模拟验证逻辑
    if (!data.email) {
      setStatus('error');
      return;
    }

    setStatus('submitting');
    // 模拟 API 调用
    setTimeout(() => {
      onSubmit(data); // 调用外部传入的回调
      setStatus('success');
    }, 100);
  };

  return { status, handleSubmit };
};

我们要测试：当调用 handleSubmit 时，状态是否按顺序变成了 validating -> submitting -> success？

// useFormHandler.test.js
import { renderHook, act } from '@testing-library/react';
import { useFormHandler } from './useFormHandler';

test('should update status in correct order', async () => {
  // 1. 创建一个 mock 函数来监听 onSubmit
  const mockOnSubmit = jest.fn();

  // 2. 渲染 Hook
  const { result } = renderHook(() => useFormHandler(mockOnSubmit));

  // 3. 获取初始状态
  expect(result.current.status).toBe('idle');

  // 4. 调用 handleSubmit
  act(() => {
    result.current.handleSubmit({ email: '[email protected]' });
  });

  // 5. 验证第一步：validating
  expect(result.current.status).toBe('validating');

  // 6. 等待异步完成
  await act(async () => {
    await new Promise((resolve) => setTimeout(resolve, 150)); // 等待 100ms + 缓冲
  });

  // 7. 验证最终状态：success
  expect(result.current.status).toBe('success');

  // 8. 验证回调被调用了
  expect(mockOnSubmit).toHaveBeenCalledWith({ email: '[email protected]' });
});

注意这里使用了 act。React 的状态更新是一个异步过程，renderHook 返回的 result 是一个 Proxy，它会自动帮你处理 act，但为了保险起见，手动包裹一下是个好习惯。

---

第七部分：处理闭包陷阱

这是 React 开发者最头疼的问题，也是测试 Hook 时最容易遇到的坑。

问题： Hook 内部的函数（比如 useEffect 的清理函数，或者事件监听器）如果捕获了旧的状态，就会导致 Bug。而 Bug 往往只有在特定的操作顺序下才会触发。

示例 4：经典的闭包 Bug

// useCount.js
export const useCount = () => {
  const [count, setCount] = React.useState(0);

  React.useEffect(() => {
    const timer = setInterval(() => {
      // 致命的 Bug：这里永远读取到的是初始的 0
      console.log(count); 
    }, 1000);

    return () => clearInterval(timer);
  }, []); // 依赖项为空，意味着只运行一次

  return { count, setCount };
};

如果你用 renderHook 测试这个，你可能会发现：控制台每隔一秒打印一次 0。这看起来很正常，因为 useEffect 确实只运行了一次。

但是，如果我们在测试中改变 count 呢？

test('should update interval when count changes', () => {
  const { result, rerender } = renderHook(() => useCount());

  // 初始状态，打印 0
  act(() => {
    result.current.setCount(1);
  });

  // 重新渲染
  rerender();

  // 此时，useEffect 的闭包里依然是 0，而不是 1
  // 虽然我们改变了 count，但定时器里的逻辑没变
});

如何测试这种隐蔽的 Bug？
我们需要模拟时间流逝。我们可以使用 jest.useFakeTimers()。

import { renderHook, act } from '@testing-library/react';
import { useCount } from './useCount';

test('should capture the latest count in useEffect', () => {
  const { result } = renderHook(() => useCount());

  // 1. 改变状态
  act(() => {
    result.current.setCount(5);
  });

  // 2. 启动定时器
  act(() => {
    jest.advanceTimersByTime(1000);
  });

  // 3. 检查日志
  // 在真实代码中，这里会打印 5
  // 在有 Bug 的代码中，这里会打印 0
  expect(console.log).toHaveBeenCalledWith(5); 
});

通过模拟时间，我们迫使 Hook 执行它的逻辑，从而暴露出闭包陷阱。

---

第八部分：实战演练——一个复杂的业务场景

为了让大家彻底理解，我们来做一个综合案例。假设我们要写一个 “实时搜索用户” 的 Hook。

需求：

1. 用户输入关键词。
2. Hook 防抖 500ms 后发起 API 请求。
3. API 返回数据后，更新 UI。
4. 如果输入为空，清空数据。

代码实现：

// useSearchUser.js
export const useSearchUser = () => {
  const [users, setUsers] = React.useState([]);
  const [loading, setLoading] = React.useState(false);
  const [keyword, setKeyword] = React.useState('');

  React.useEffect(() => {
    // 防抖逻辑
    const timer = setTimeout(() => {
      if (!keyword.trim()) {
        setUsers([]);
        return;
      }

      setLoading(true);
      // 模拟 API 调用
      fetchUsers(keyword).then((data) => {
        setUsers(data);
        setLoading(false);
      });
    }, 500);

    return () => clearTimeout(timer);
  }, [keyword]);

  return { users, loading, keyword, setKeyword };
};

// 模拟 API
const fetchUsers = (kw) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve([{ id: 1, name: `${kw} User` }]);
    }, 300);
  });
};

测试用例编写：

// useSearchUser.test.js
import { renderHook, waitFor } from '@testing-library/react';
import { useSearchUser } from './useSearchUser';

jest.useFakeTimers();

test('should debounce search and return users', async () => {
  const { result } = renderHook(() => useSearchUser());

  // 1. 输入关键词
  act(() => {
    result.current.setKeyword('Alice');
  });

  // 2. 此时 loading 应该还是 false，因为还在 500ms 防抖期内
  expect(result.current.loading).toBe(false);
  expect(result.current.users).toEqual([]);

  // 3. 快进时间，触发防抖
  act(() => {
    jest.advanceTimersByTime(500);
  });

  // 4. 等待 API 完成
  await waitFor(() => {
    expect(result.current.loading).toBe(false);
  });

  // 5. 验证结果
  expect(result.current.users).toEqual([{ id: 1, name: 'Alice User' }]);
});

test('should clear users when keyword is empty', () => {
  const { result } = renderHook(() => useSearchUser());

  act(() => {
    result.current.setKeyword('Bob');
  });
  jest.advanceTimersByTime(500);
  waitFor(() => expect(result.current.users.length).toBeGreaterThan(0));

  // 6. 清空输入
  act(() => {
    result.current.setKeyword('');
  });

  // 7. 快进时间，触发清理逻辑
  act(() => {
    jest.advanceTimersByTime(500);
  });

  // 8. 验证数据被清空
  expect(result.current.users).toEqual([]);
});

这个测试案例完美地覆盖了：

1. 状态管理（users, loading）。
2. 副作用（useEffect 中的定时器和 API 调用）。
3. 异步逻辑（waitFor）。
4. 边界条件（空关键词）。
5. 时间模拟（jest.advanceTimersByTime）。

---

第九部分：最佳实践与避坑指南

好了，讲了这么多理论和代码，最后送大家几条保命锦囊。

1. 不要测试实现细节：

   • 坏的测试：expect(hookInstance.state.count).toBe(0)。
   • 好的测试：expect(hookInstance.result.current.count).toBe(0)。
   • 我们测试的是 Hook 的行为（Behavior），而不是它的内部变量（Implementation）。因为内部变量可能会重构，但行为不会。

2. 善用 renderHook，不要滥用手动渲染：

   • 如果你的 Hook 很简单，没有复杂的副作用依赖，用 renderHook。
   • 如果你的 Hook 需要测试渲染流程，或者你需要模拟特定的 Context/Store，用手动渲染。

3. Mock 外部依赖：

   • 不要在单元测试里真的去请求你的后端 API。那太慢了，而且容易因为网络问题失败。使用 jest.fn() 或者 jest.mock()。

4. 测试回调函数的调用次数：

   • 使用 jest.fn()。这是测试函数式组件和 Hooks 最强大的武器。它能告诉你：这个函数被调用了 1 次，2 次，还是 0 次？参数是什么？

5. 处理内存泄漏：

   • 如果你的 Hook 注册了事件监听器，一定要在 useEffect 的清理函数里移除它。测试时，renderHook 会自动卸载组件并触发清理函数，但如果你手动渲染，记得手动清理。

---

结语

测试 React Hooks，本质上是在测试逻辑。

当你把一个复杂的业务逻辑从组件里剥离出来，变成一个纯函数时，你就获得了测试它的能力。不要害怕测试，不要觉得测试会增加工作量。

相反，测试是防止你深夜对着屏幕发呆的最佳武器。当你写出那个测试用例，看着它绿了的时候，那种快乐，比写出一个酷炫的特效还要爽。

记住，优秀的代码是写出来的，更是测出来的。 特别是当你使用了 React Hooks 这种充满魔法的技术时，测试就是你手里的魔杖，用来驱散那些看不见的 Bug 魔鬼。

好了，今天的讲座就到这里。现在，去写一个 Hook，然后去测试它吧！祝你们都能写出没有 Bug 的代码！

（全场掌声，我擦了擦汗下台）