SWR Mutation测试的推荐方式及测试策略探讨

请问测试SWR中的mutation有什么推荐方式？以下是示例代码：

function Index() {
  const { data, mutate } = useSWR("/api/user", fetch);

  if (data.loggedIn) {
    return (
      <Button
        onClick={() => {
          logout();
          mutate(); // after logging in/out, we mutate the SWR
        }}
      >
        Logout
      </Button>
    );
  } else {
    // login
    return (<h1>Please login</h1>)
  }
}

现有流程：logout -> mutate swr -> show login form

我认为不应测试实现细节，而应测试变更后用户实际看到的内容，例如：

expect(mutate).toHaveBeenCalled('/logout'); // bad 
expect(screen.getByText('Please login')).toBeInTheDocument(); // correct

想了解大家对此的普遍看法是什么？

普遍看法总结 #

社区主流观点和你一致：优先测试用户可见的行为，而非实现细节，核心原因如下：

• 实现细节（比如是否调用mutate、调用参数）可能随业务迭代或库版本更新变化，但用户的核心体验（点击登出后显示登录提示）是稳定的。测试用户行为能让测试更健壮，不会因内部逻辑调整频繁失效。
• 这类测试更贴近真实场景，能有效验证功能是否真正可用。比如若mutate调用成功但接口返回异常，用户依然看不到登录提示，此时测试实现细节会误判通过，而测试UI表现能准确发现问题。

当然也存在少量例外场景需要关注实现细节：

• 当mutate包含特殊逻辑（比如自定义缓存更新、乐观UI处理）且直接影响体验时，可以针对性测试这些逻辑，但仍需结合最终UI表现，而非孤立测试mutate调用。
• 单元测试层面，若单独测试封装的mutate逻辑（比如请求+缓存更新的函数），可以测试其内部行为，但集成测试和E2E测试仍要以用户视角为主。

简言之，测试的核心应该是「这个功能对用户来说是否正常工作」，而非「代码是否按预想调用了某个方法」。

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