如何为需从API获取Token的ViewModel编写单元测试？

关于Dummy Token的使用 #

肯定要用dummy token，单元测试的核心是隔离外部依赖——你要测的是ViewModel本身的逻辑，不是真实的DataStore、API服务这些外部组件。直接依赖真实的getSession()获取Token，就会因为未登录返回null，把测试逻辑搅乱。正确的做法是把获取Token的依赖（比如DataStore封装类、Session管理类）Mock掉，让它在测试时返回你预设的dummy token，这样就能完全控制测试环境。

单元测试无法运行的排查&修复 #

你遇到的DataStore返回null的问题，本质是没做好依赖隔离。按下面的步骤调整：

1. Mock Token依赖：用Mockito、MockK这类框架，把ViewModel依赖的Token获取组件Mock出来，强制返回预设的dummy token（比如"test_dummy_token"），彻底绕开真实的DataStore。
2. 确保依赖注入：ViewModel的构造函数要通过依赖注入传入Token服务、API服务，这样测试时才能替换成Mock实例，而不是在内部直接创建真实对象。

针对你的测试验证点，给具体的测试逻辑：

数据加载成功场景 #

• Mock Token服务返回有效dummy token
• Mock API服务返回你预设的测试数据（比如固定长度的列表，第一条数据有明确的字段值）
• 调用ViewModel的加载方法
• 断言：
  • 数据列表非空
  • 列表长度和预设的测试数据长度一致
  • 列表第一条数据的字段（比如id、内容）和预设值完全匹配

数据不可用场景 #

分两种情况测试：

• Token无效/缺失：Mock Token服务返回null或空字符串，触发加载后，断言数据为空或null
• API返回空/错误：Mock Token有效，但API返回空列表或抛出异常，断言数据为空或null

是否需要提供GitHub仓库？ #

如果按上面的步骤调整后还是跑不起来，提供GitHub仓库会大幅提升排查效率。因为能直接看到你的代码结构、依赖注入方式、Mock的具体写法，更容易定位问题——比如Mock没生效、ViewModel里有未处理的空Token分支、测试断言逻辑写错了等。

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