React Testing Library 完整指南：用更接近用户的方式构建可维护测试

React Testing Library 这些年越来越常见，不是因为它让测试写起来更短，而是因为它迫使团队回到一个更健康的问题上：用户到底能不能完成操作。

如果测试主要围绕组件实例、内部 state 和实现细节展开，重构时测试通常会先坏掉。RTL 的价值，就在于尽量让测试站在用户视角，而不是站在组件内部视角。

先理解 RTL 的核心原则：测试行为，不测试实现细节

RTL 最重要的心智模型只有一句话：越接近用户如何使用页面，测试就越有价值。

这意味着团队更应该验证：

文本是否出现
按钮是否可点击
表单报错是否可感知
异步加载后页面是否进入正确状态

而不是验证：

某个 hook 是否被调用几次
某个 state 内部值是否变化
某个子组件实例是否存在

查询顺序决定测试的稳定性

RTL 推荐的查询顺序，本质上是在提醒团队优先使用真实语义。

import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

it('submits the form after valid input', async () => {
  const user = userEvent.setup()
  render(<LoginForm />)

  await user.type(screen.getByLabelText(/email/i), 'team@htmlpage.cn')
  await user.type(screen.getByLabelText(/password/i), 'safe-password')
  await user.click(screen.getByRole('button', { name: /sign in/i }))

  expect(await screen.findByText(/welcome back/i)).toBeInTheDocument()
})

优先使用 getByRole、getByLabelText 这类查询，不只是为了写法规范，更是因为它会逼迫组件本身具备更好的可访问性。

异步测试要验证用户看到的状态变化

很多团队在写异步测试时，容易直接等待某个 mock 被调用，然后结束断言。这样做能测到实现，却未必测到用户体验。

更稳的做法是把状态变化写完整：

加载态是否出现
成功后是否出现结果
失败后是否显示明确错误

it('shows error message when request fails', async () => {
  server.use(http.post('/api/login', () => HttpResponse.json({ message: 'Invalid credentials' }, { status: 401 })))

  render(<LoginForm />)

  await userEvent.type(screen.getByLabelText(/email/i), 'wrong@example.com')
  await userEvent.type(screen.getByLabelText(/password/i), 'bad-pass')
  await userEvent.click(screen.getByRole('button', { name: /sign in/i }))

  expect(await screen.findByRole('alert')).toHaveTextContent(/invalid credentials/i)
})