📚 课程目录第1章 ViewModel状态注入的必要性

1. ViewModel状态注入的必要性：测试隔离、状态可控、减少依赖、提高覆盖率

在Android应用架构中，ViewModel作为UI与数据层之间的桥梁，其可测试性直接影响整体工程质量。传统ViewModel在构造函数中直接实例化依赖项或通过ViewModelProvider.Factory硬编码依赖，导致单元测试时状态不可预设、依赖不可替换，测试用例之间互相污染。状态注入（State Injection）通过将初始状态和依赖通过构造函数显式传入，从根本上解决了这些问题。本章从测试隔离、状态可控、减少依赖、提高覆盖率四个维度剖析其必要性。

1.1 传统ViewModel的测试痛点

状态不可控： 内部状态由异步操作或生命周期事件驱动，测试难以在指定时刻断言特定UI状态。
依赖硬编码： Repository、UseCase等直接在ViewModel内部new()，测试时无法替换为Mock或Fake。
测试隔离差： 单例或静态变量导致多个测试共享状态，出现顺序敏感型失败。
覆盖率低： 边界条件（如网络错误、空数据、权限拒绝）难以触发，测试仅覆盖Happy Path。

1.2 状态注入的核心原理

状态注入的核心是将ViewModel所依赖的初始状态对象和业务依赖接口通过构造函数参数传入，而不是在ViewModel内部自行创建。这一模式使得每个测试可以携带独立的初始状态与完全可控的Mock依赖，彻底消除外部副作用。基本的接口形式如下：

class MyViewModel(
    private val initialState: MyUiState,
    private val repository: MyRepositoryInterface
) : ViewModel() {
    private val _uiState = MutableStateFlow(initialState)
    val uiState: StateFlow<MyUiState> = _uiState.asStateFlow()
}

1.3 必要性维度详解

维度	传统ViewModel问题	状态注入后优势
测试隔离	共享状态导致测试顺序依赖，失败难以复现	每个测试用例创建全新ViewModel实例，注入独立状态，互不干扰
状态可控	状态由内部逻辑决定，测试只能等待异步结果	可直接注入任意期望状态（Loading、Success、Error），覆盖所有分支
减少依赖	ViewModel直接依赖具体实现类，无法替换	依赖注入抽象接口，测试时传入Mock，仅需关注接口行为
提高覆盖率	难以模拟错误、空数据、超时等边界条件	注入任意状态组合 + Mock返回值，轻松覆盖100%分支

1.4 实现流程概述（后续章节展开）

定义UI状态密封类（Sealed Class）或数据类，包含所有可能的分支。
改造ViewModel构造函数，将初始状态和业务依赖作为参数（不使用默认参数，强制外部注入）。
创建测试夹具（Test Fixture）工厂，提供预设状态与预配置Mock。
在单元测试中实例化ViewModel并传入夹具，验证状态发射与UI行为。

1.5 代码示例：问题对比

传统方式（不可测试）：

class UserViewModel : ViewModel() {
    private val repository = UserRepository()  // 硬编码
    private val _uiState = MutableStateFlow(UserUiState.Loading)
    val uiState: StateFlow<UserUiState> = _uiState.asStateFlow()
    
    fun loadUser(id: String) {
        viewModelScope.launch {
            _uiState.value = UserUiState.Loading
            try {
                val user = repository.fetchUser(id)
                _uiState.value = UserUiState.Success(user)
            } catch (e: Exception) {
                _uiState.value = UserUiState.Error(e.message ?: "Unknown")
            }
        }
    }
}

采用状态注入后：

class UserViewModel(
    private val initialState: UserUiState,
    private val repository: UserRepositoryInterface
) : ViewModel() {
    private val _uiState = MutableStateFlow(initialState)
    val uiState: StateFlow<UserUiState> = _uiState.asStateFlow()
    
    fun loadUser(id: String) {
        viewModelScope.launch {
            _uiState.value = UserUiState.Loading
            try {
                val user = repository.fetchUser(id)
                _uiState.value = UserUiState.Success(user)
            } catch (e: Exception) {
                _uiState.value = UserUiState.Error(e.message ?: "Unknown")
            }
        }
    }
}

单元测试示例：

@Test
fun `given initial error state when constructed then UI state is error`() {
    val repo = mockk<UserRepositoryInterface>()
    val viewModel = UserViewModel(
        initialState = UserUiState.Error("Initial unrecoverable error"),
        repository = repo
    )
    assertEquals(
        UserUiState.Error("Initial unrecoverable error"),
        viewModel.uiState.value
    )
}

1.6 调试技巧与常见错误

调试技巧： 在测试中注入一个带日志记录的Fake Repository，使用coEvery { repository.fetchUser(any()) } coAnswers { /* log call */ original() }，可以清晰观察每次调用参数与顺序。配合TestCoroutineDispatcher手动控制时间，避免真实延迟。

常见错误：

遗忘将状态类声明为data class或open，导致测试中无法直接构造或继承。
在ViewModel构造函数中使用默认参数（如initialState: UserUiState = UserUiState.Loading），测试仍可能无意中依赖默认值，应强制要求外部传入。
注入的依赖对象包含Activity或Context引用，造成泄漏或难以Mock。

1.7 性能与稳定性优化

对象轻量化： 确保注入的状态对象本身不包含大数据或资源引用，仅作为纯数据容器。
不可变状态： 使用data class + val或Kotlin不可变集合，保证线程安全，避免多测试场景下的竞态。
工厂化生产： 对于复杂ViewModel，借助AssistedInject（Dagger Hilt）或SavedStateHandle将状态注入与依赖注入框架结合，保持构造逻辑简洁。
缓存策略： 注入的Mock/Fake依赖应每次测试重新创建，避免使用单例或全局变量导致状态残留。

1.8 关系图：状态注入如何在测试中解耦

1.9 总结

ViewModel状态注入是提升Android测试质量的基石。它通过构造函数强制注入初始状态与依赖接口，彻底解决了测试隔离、状态可控、依赖解耦和覆盖率瓶颈四大问题。后续章节将逐步构建完整的夹具框架，涵盖状态定义、注入机制、测试配置以及高级特性（如SavedStateHandle集成、参数化夹具）。掌握此模式，你将能够编写出稳定、可维护且覆盖完整的UI测试。