>在掌握了 Compose 状态管理、ViewModel 架构以及协程异步编程之后，我开始认真思考一个问题：我们写了这么多代码，怎么知道它们是正确的？

在前端世界，Jest、Vitest、React Testing Library 早已是工程化标配。但转到 Kotlin/Compose 之后，很多前端同学（包括我）会产生困惑：测试框架是哪个？怎么 mock？StateFlow 怎么断言？

本文将从前端开发者的视角，系统介绍 Kotlin Multiplatform 项目的测试体系：从最基础的单元测试，到 ViewModel 的状态测试，再到测试金字塔的整体认知。

---

## 快速体验 单元测试与 UI 测试

### 运行本课程示例

在深入学习前，先把示例跑起来，直观感受测试体系的效果：

#### Web 版本（推荐给前端开发者）

```bash
# 克隆项目（如果还没有）
git clone <repository-url>
cd learn-jetpack-compose

# 运行本课程的 WASM 版本
./gradlew :lesson-20-testing:wasmJsBrowserDevelopmentRun
```

运行成功后，浏览器会自动打开 `http://localhost:8080`，你将看到：

- **测试金字塔**：交互式图解，理解单元测试 / 集成测试 / E2E 测试的分层关系
- **单元测试用例展示**：直接在 UI 中查看 `CalculatorTest.kt` 的写法和前端对比
- **ViewModel 测试思路**：FakeRepository 模式、StateFlow 断言方法

💡 **前端开发者的优势**：WASM 版本直接在浏览器中运行，体验和开发普通 Web 应用一样！

#### 运行测试（重点）

```bash
# 运行所有测试（Desktop JVM 平台执行）
./gradlew :lesson-20-testing:allTests

# 只运行 Desktop JVM 测试
./gradlew :lesson-20-testing:desktopTest

# 查看测试报告（HTML 格式）
open build/reports/tests/desktopTest/index.html
```

**效果预览：**

![企业微信截图_93c9b081-c2c9-48b8-b9a9-7611070b2e08.png](https://developer.qcloudimg.com/http-save/yehe-320080/59f7287aa8e651015c4f61d77ae63687.png)
---

## 从前端视角理解测试

### 测试框架对比

在前端，我们用 Jest 或 Vitest 写测试：

**前端（Jest/Vitest）：**
```javascript
import { add, divide } from './calculator'

describe('Calculator', () => {
  it('加法正确', () => {
    expect(add(2, 3)).toBe(5)
  })

  it('除以零应抛出错误', () => {
    expect(() => divide(10, 0)).toThrow('除数不能为零')
  })
})
```

**Kotlin（kotlin-test）：**
```kotlin
import kotlin.test.*

class CalculatorTest {
    private val calc = Calculator()

    @Test
    fun `加法正确`() {
        assertEquals(5.0, calc.add(2.0, 3.0))
    }

    @Test
    fun `除以零应抛出异常`() {
        assertFailsWith<ArithmeticException> {
            calc.divide(10.0, 0.0)
        }
    }
}
```

**相似点：**
- 都用注解/函数标记测试方法
- 都有断言 API（`toBe` ↔ `assertEquals`，`toThrow` ↔ `assertFailsWith`）
- 测试方法都是独立隔离的

**差异点：**
- Kotlin 用类组织测试，前端用 `describe` 块
- Kotlin 支持反引号方法名，可以写中文描述
- Kotlin 的异常断言语法更简洁

---

## 测试金字塔

### 核心理念

测试金字塔（Testing Pyramid）是软件测试的基础认知模型，由 Mike Cohn 提出：

```
         /\
        /  \       ← UI / E2E 测试（少量、慢、昂贵）
       /----\
      /      \     ← 集成测试（适量、中等速度）
     /--------\
    /          \   ← 单元测试（大量、快速、廉价）
   /____________\
```

**三层含义：**

| 层级 | 数量 | 速度 | 代价 | 覆盖范围 |
|------|------|------|------|----------|
| 单元测试 | 多 | 极快（毫秒级） | 低 | 单个函数/类 |
| 集成测试 | 中 | 中等（秒级） | 中 | 多模块协作 |
| UI/E2E 测试 | 少 | 慢（分钟级） | 高 | 完整用户流程 |

### 前端工具对应

| 层级 | 前端 | Kotlin/Compose |
|------|------|----------------|
| 单元测试 | Jest / Vitest | kotlin-test |
| 组件测试 | React Testing Library / @testing-library/vue | 暂无直接等价（重逻辑测试） |
| E2E 测试 | Playwright / Cypress | Maestro / Appium |

**我的实践经验：**
在前端，我习惯写组件测试（Testing Library 那种）。但在 Compose 中，目前官方 UI 测试方案对 KMP 的支持还不完善，所以 **重点写逻辑层的单元测试** 反而是更现实的策略——而且这往往意味着要把业务逻辑从 Composable 中抽离出来，这本身就是好的架构实践。

---

## 单元测试实战：Calculator

### 被测目标

```kotlin
// src/commonMain/kotlin/org/easonxie/lesson20/calculator/Calculator.kt
class Calculator {

    fun add(a: Double, b: Double): Double = a + b

    fun subtract(a: Double, b: Double): Double = a - b

    fun multiply(a: Double, b: Double): Double = a * b

    fun divide(a: Double, b: Double): Double {
        if (b == 0.0) throw ArithmeticException("除数不能为零")
        return a / b
    }

    fun average(numbers: List<Double>): Double {
        if (numbers.isEmpty()) throw IllegalArgumentException("列表不能为空")
        return numbers.sum() / numbers.size
    }
}
```

这是一个纯 Kotlin 类，不依赖任何 UI 框架。**纯函数 / 纯逻辑** 是最容易测试的代码。

### 完整测试代码

```kotlin
// src/commonTest/kotlin/org/easonxie/lesson20/CalculatorTest.kt
import org.easonxie.lesson20.calculator.Calculator
import kotlin.test.*

class CalculatorTest {

    // 每个测试方法共享同一实例（无状态，安全）
    private val calc = Calculator()

    // ✅ 最简单的断言：assertEquals(期望值, 实际值)
    @Test
    fun `加法 - 正数相加`() {
        assertEquals(5.0, calc.add(2.0, 3.0))
    }

    // ✅ 边界值：负数
    @Test
    fun `加法 - 含负数`() {
        assertEquals(-1.0, calc.add(2.0, -3.0))
    }

    // ✅ 异常路径测试：assertFailsWith
    // 类比 Jest：expect(() => fn()).toThrow(Error)
    @Test
    fun `除法 - 除以零应抛出异常`() {
        val exception = assertFailsWith<ArithmeticException> {
            calc.divide(10.0, 0.0)
        }
        // 还可以验证异常信息
        assertTrue(exception.message?.contains("零") == true)
    }

    // ✅ 空集合异常
    @Test
    fun `平均值 - 空列表应抛出异常`() {
        assertFailsWith<IllegalArgumentException> {
            calc.average(emptyList())
        }
    }
}
```

### 核心断言 API 对照表

| 功能 | Jest/Vitest | kotlin-test |
|------|-------------|-------------|
| 相等断言 | `expect(a).toBe(b)` | `assertEquals(b, a)` |
| 不等断言 | `expect(a).not.toBe(b)` | `assertNotEquals(b, a)` |
| 为真 | `expect(x).toBeTruthy()` | `assertTrue(x)` |
| 为假 | `expect(x).toBeFalsy()` | `assertFalse(x)` |
| 为 null | `expect(x).toBeNull()` | `assertNull(x)` |
| 抛出异常 | `expect(() => fn()).toThrow(Error)` | `assertFailsWith<SomeException> { fn() }` |
| 包含元素 | `expect(arr).toContain(x)` | `assertContains(arr, x)` |

---

## ViewModel 测试实战：TodoViewModel

### 架构设计

要让 ViewModel 可测，关键是**依赖注入 + 接口**：

```
TodoViewModel
    │
    └── TodoRepository（接口）
            ├── InMemoryTodoRepository（生产环境）
            └── FakeTodoRepository（测试专用）
```

前端类比：就像把 API 调用抽象成 `interface UserService`，测试时注入 `mockUserService`。

### ViewModel 代码

```kotlin
// 注意：构造函数接受 repository 参数，默认用生产实现
class TodoViewModel(
    private val repository: TodoRepository = InMemoryTodoRepository()
) : ViewModel() {

    data class UiState(
        val items: List<TodoItem> = emptyList(),
        val inputText: String = "",
        val filter: Filter = Filter.ALL
    )

    private val _uiState = MutableStateFlow(UiState())
    val uiState: StateFlow<UiState> = _uiState.asStateFlow()

    fun addTodo() {
        val title = _uiState.value.inputText.trim()
        if (title.isBlank()) return
        repository.add(title)
        _uiState.update { it.copy(items = repository.getAll(), inputText = "") }
    }

    // ... toggleTodo, deleteTodo, clearCompleted
}
```

### 测试代码

```kotlin
class TodoViewModelTest {

    private lateinit var fakeRepo: FakeTodoRepository
    private lateinit var viewModel: TodoViewModel

    // @BeforeTest 类比 Jest 的 beforeEach
    @BeforeTest
    fun setUp() {
        fakeRepo = FakeTodoRepository()
        viewModel = TodoViewModel(repository = fakeRepo)  // 注入 Fake
    }

    @Test
    fun `初始状态应为空列表`() {
        assertTrue(viewModel.uiState.value.items.isEmpty())
    }

    @Test
    fun `添加Todo后列表长度增加`() {
        viewModel.onInputChange("买牛奶")
        viewModel.addTodo()

        // 直接读取 StateFlow 的当前值，类比 Pinia 的 store.items
        val state = viewModel.uiState.value
        assertEquals(1, state.items.size)
        assertEquals("买牛奶", state.items[0].title)
    }

    @Test
    fun `空白输入不应添加Todo`() {
        viewModel.onInputChange("   ")
        viewModel.addTodo()

        assertTrue(viewModel.uiState.value.items.isEmpty())
    }

    @Test
    fun `切换完成状态`() {
        viewModel.onInputChange("写测试")
        viewModel.addTodo()

        val id = viewModel.uiState.value.items[0].id
        viewModel.toggleTodo(id)

        assertTrue(viewModel.uiState.value.items[0].isCompleted)
    }
}
```

### FakeTodoRepository

```kotlin
// 测试专用的 Fake 实现
class FakeTodoRepository : TodoRepository {

    val items = mutableListOf<TodoItem>()
    private var nextId = 1

    override fun getAll() = items.toList()

    override fun add(title: String): TodoItem {
        val item = TodoItem(id = nextId++, title = title)
        items.add(item)
        return item
    }

    override fun toggle(id: Int): TodoItem? {
        val index = items.indexOfFirst { it.id == id }
        if (index == -1) return null
        val updated = items[index].copy(isCompleted = !items[index].isCompleted)
        items[index] = updated
        return updated
    }

    override fun delete(id: Int) = items.removeAll { it.id == id }
    override fun clearCompleted() = items.removeAll { it.isCompleted }
}
```

**关键教训：**
- 通过构造函数注入依赖，让测试可以替换任何依赖
- Fake 比 Mock 框架更简单直接（不需要额外的 MockK 依赖）
- `@BeforeTest` 确保每个测试方法都用全新的实例，避免测试间污染

---

## 关于 runTest 和协程测试

当 ViewModel 中有挂起函数时，需要 `runTest`：

**前端（async/await）：**
```javascript
it('异步加载数据', async () => {
  await store.fetchData()
  expect(store.items).toHaveLength(3)
})
```

**Kotlin（runTest）：**
```kotlin
@Test
fun `异步加载数据`() = runTest {
    viewModel.fetchData()  // suspend 函数
    // runTest 会自动推进虚拟时钟，不需要真实等待
    assertEquals(3, viewModel.uiState.value.items.size)
}
```

`runTest` 来自 `kotlinx-coroutines-test`，它提供了虚拟时钟，测试中的 `delay(1000)` 会立即完成，不需要真实等待 1 秒。

---

## 项目结构说明

```
lesson-20-testing/
├── build.gradle.kts                     # 多平台构建配置
├── src/
│   ├── commonMain/
│   │   └── kotlin/org/easonxie/lesson20/
│   │       ├── App.kt                   # 主界面（Tab 导航）
│   │       ├── calculator/
│   │       │   └── Calculator.kt        # 被测业务逻辑
│   │       ├── todo/
│   │       │   ├── TodoItem.kt          # 数据模型
│   │       │   ├── TodoRepository.kt   # 接口 + 生产实现
│   │       │   └── TodoViewModel.kt    # ViewModel
│   │       └── demos/
│   │           ├── UnitTestShowcaseDemo.kt
│   │           ├── ViewModelTestDemo.kt
│   │           └── TestPyramidDemo.kt
│   ├── commonTest/                      # 跨平台测试（JVM 执行）
│   │   └── kotlin/org/easonxie/lesson20/
│   │       ├── CalculatorTest.kt
│   │       └── TodoViewModelTest.kt
│   ├── wasmJsMain/                      # Web 平台入口
│   └── desktopMain/                     # 桌面平台入口
```

---

## 踩过的坑

**踩坑 1：测试间状态污染**

一开始我在类级别定义了 `var viewModel = TodoViewModel()`，结果多个测试共享同一个实例，测试 B 会受到测试 A 的影响，导致莫名奇妙的失败。

解决方案：用 `lateinit var` + `@BeforeTest` 每次重新创建实例。

**踩坑 2：直接实例化 InMemoryTodoRepository**

一开始写 `val viewModel = TodoViewModel(InMemoryTodoRepository())`，但这样就没有可控的"观察点"——你不知道 repository 里存了什么。

解决方案：用 FakeRepository，它暴露了 `val items: MutableList<TodoItem>`，测试可以直接检查底层数据。

**踩坑 3：忽视纯逻辑的可测性**

一开始把所有逻辑写在 Composable 里，导致根本没法测试。意识到这个问题后，把业务逻辑都移到 Calculator / ViewModel 等纯 Kotlin 类，测试难度瞬间降低了 80%。

---

## 总结

通过本文的学习，我们从前端开发者的视角探索了 Kotlin/Compose 的测试体系。

**核心要点：**
- **kotlin-test** 是跨平台测试框架，对应前端的 Jest/Vitest
- **测试金字塔** 告诉我们要重视单元测试，少写 E2E
- **依赖注入 + 接口** 是让代码可测的关键，类比前端的 mock
- **`assertFailsWith`** 测试异常路径，`@BeforeTest` 隔离测试状态

**前端开发者的优势：**
- 测试思维是相通的：输入 → 执行 → 断言
- Mock 模式（FakeRepository）和前端的 `vi.mock()` 如出一辙
- 对"可测试设计"（接口隔离、依赖注入）已经有直觉

**需要适应的地方：**
- Kotlin 用类组织测试，而不是 `describe` 嵌套
- 目前 Compose UI 的跨平台测试方案尚不成熟，重点放在逻辑层测试
- `runTest` 的协程测试有学习曲线，但原理和 `async/await` 一致


在掌握了 Compose 状态管理、ViewModel 架构以及协程异步编程之后，我开始认真思考一个问题：我们写了这么多代码，怎么知道它们是正确的？

前端开发者的 Kotlin 之旅：单元测试与 UI 测试实战

前端开发工程师

前端

编程语言

测试

本文从前端开发者视角解析Kotlin/Compose测试体系，对比Jest与kotlin-test框架差异，详解单元测试、ViewModel测试方法，分享测试金字塔实践心得。重点讲解FakeRepository模式、StateFlow断言技巧及协程测试方案，帮助开发者构建可测试的Kotlin跨平台应用架构。

软件测试

单元测试

集成测试

Kotlin

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

前端开发者的 Kotlin 之旅：单元测试与 UI 测试实战-腾讯云开发者社区-腾讯云

前端开发者的 Kotlin 之旅：单元测试与 UI 测试实战

前端开发者的 Kotlin 之旅：单元测试与 UI 测试实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐