Android单元测试基础

单元测试用于验证应用中最小单元（函数或类）的行为是否正确。在 Android/Kotlin 项目中，本地单元测试通常放在 module/src/test/ 目录下，使用 JUnit4 框架编写。要启用测试，需要在 Gradle 中添加依赖，例如

testImplementation "junit:junit:版本号"（JUnit4）和 testImplementation "io.mockk:mockk:版本号"（MockK）。

每个测试类中包含一个或多个用 @Test 注解标记的方法，在方法体内调用被测函数并使用断言验证输出。

1. class EmailValidatorTest {

2. @Test

3. fun emailValidator_CorrectEmailSimple_ReturnsTrue() {

4. assertTrue(EmailValidator.isValidEmail("name@example.com"))

5. }

6. }

AI写代码

该示例中，测试方法通过 assertTrue 检查 isValidEmail() 的返回值。在编写单元测试时，我们通常将外部依赖（如数据库、网络、Android 框架等）替换为可控的测试替身（如 mock 对象），以实现隔离测试。常用的断言库包括 JUnit Assert、Hamcrest、Truth 等。

测试替身

单元测试中的测试替身（Test Doubles）

依赖隔离，核心逻辑：

关键概念解析

替身类型	作用场景	示例
Mock	验证交互行为	检查是否调用了数据库API
Stub	返回预设数据	固定返回用户{id:1, name:测试}
Fake	简化实现替代真实服务	内存数据库替代MySQL
Spy	记录调用信息（Mock的变体）	记录网络请求次数
Dummy	填充参数（无逻辑）	new Object()占位

在Android测试中的典型应用

1. // 使用Mockito框架示例

2. @Mock

3. Database mockDB; // 创建数据库Mock

5. @Test

6. public void testUserSave() {

7. // 1. 设置Stub行为

8. when(mockDB.save(any(User.class))).thenReturn(true);

10. // 2. 执行被测方法

11. service.saveUser(new User("test"));

13. // 3. 验证Mock交互

14. verify(mockDB).save(any(User.class));

15. }

AI写代码

核心价值

• 🛡️ 隔离性：避免测试因网络/DB故障而失败
• ⚡ 加速测试：移除真实IO操作（原需200ms→2ms）
• 🔍 行为验证：确保调用次数/参数符合预期
• 🧪 边界覆盖：轻松模拟异常场景（如：when(...).thenThrow(...)）

MockK 概念与常用用法

MockK 是一个专为 Kotlin 设计的模拟测试框架，相比 Mockito 等 Java 库，MockK 自然支持 Kotlin 的特性，如 final 类、扩展函数和协程。使用 MockK 可以方便地创建接口或类的 mock 对象，并通过 DSL 定义其行为。最简单的使用方法如下：

1. val car = mockk<Car>() // 创建 Car 类的 mock 对象

2. every { car.drive(Direction.NORTH) } returns Outcome.OK // 定义方法返回值

3. car.drive(Direction.NORTH) // 调用时返回 OK

4. verify { car.drive(Direction.NORTH) } // 验证方法被调用

5. confirmVerified(car)

AI写代码

以上示例来自 MockK 官方文档。其中 mockk<T>() 会创建一个 严格模式（strict）的 mock 对象，需要显式定义其所有行为（使用 every { ... } returns ...）。

什么叫做严格模式

1. 什么是严格模式？

• 在 MockK 中，严格模式（也称为标准模式）意味着 mock 对象会严格执行以下规则：
  • 所有对 mock 对象方法的调用都必须预先声明（即使用 every 块定义行为）。
  • 如果调用了一个没有预先声明的方法，MockK 会立即抛出异常（MockKException: no answer found）。

例如：

1. val car = mockk<Car>() // 创建严格模式的 mock 对象

3. // 未定义行为时调用方法 → 抛出异常！

4. car.drive(50) // 抛出 no answer found 异常

AI写代码

2. 显式定义行为

使用 every { ... } returns ... 结构为 mock 对象的方法定义行为：

every { car.drive(50) } returns "Driving at 50 km/h"

AI写代码

• every 块：声明一个预期调用的行为。
• returns：指定该方法调用的返回值。

此时调用 car.drive(50) 会返回 "Driving at 50 km/h"。

3. 为何需要显式定义所有行为？

• 避免隐藏错误：严格模式强制测试编写者明确指定 mock 对象的所有预期行为。这有助于暴露测试中的隐含假设或遗漏的依赖调用。
• 提高测试可靠性：确保测试只关注预先定义的行为，避免因意外调用导致的假阳性/假阴性结果。

4. 未定义行为的后果

如果在严格模式下调用未定义的方法，会收到如下错误：

io.mockk.MockKException: no answer found for: Car(#1).drive(50)

AI写代码

5. 对比：严格模式 vs 松弛模式

模式	是否需要显式定义行为	未定义行为时的处理
严格模式	是	抛出异常
松弛模式	否	返回默认值（null, 0 等）

松弛模式的创建方式：

val relaxedCar = mockk<Car>(relaxed = true) // 不会因未定义行为抛出异常

AI写代码

6. 何时使用严格模式？

• 推荐场景：
  1. 需要精确控制 mock 行为的测试。
  1. 验证代码是否按预期调用了特定方法（通常结合 verify）。
• 不推荐场景：当 mock 对象有许多不重要的方法（如纯数据模型），使用严格模式会写大量 every 块，此时可改用松弛模式。

7. 完整示例

1. // 定义类

2. class Car {

3. fun drive(speed: Int): String = "Real driving: $speed km/h"

4. }

6. // 测试

7. @Test

8. fun testStrictMock() {

9. // 1. 创建严格模式 mock

10. val car = mockk<Car>()

12. // 2. 显式定义行为

13. every { car.drive(50) } returns "Mocked driving at 50 km/h"

15. // 3. 调用已定义方法 → 成功

16. assertEquals("Mocked driving at 50 km/h", car.drive(50))

18. // 4. 调用未定义方法 → 抛出异常！

19. assertFailsWith<MockKException> {

20. car.drive(100) // 未定义 100 的行为

21. }

22. }

AI写代码

总结

• mockk<T>() 创建的是严格模式的 mock 对象。
• 必须用 every { ... } returns ... 为其每个需要调用的方法定义行为。
• 严格模式能提高测试的精确性，但会增加样板代码。根据场景选择是否使用松弛模式（relaxed = true）。### 详细解释：mockk<T>() 创建严格模式（Strict Mode）的 Mock 对象

核心概念：严格模式 (Strict Mode)

val myService = mockk<MyService>()  // 创建严格模式的 mock 对象

AI写代码

• 行为必须显式定义

  • 在严格模式下，mock 对象的所有交互行为都必须预先声明
  • 如果调用了未定义的方法，会立即抛出异常：
    io.mockk.MockKException: no answer found for: MyService(#1).getData()

• 定义行为的方式
  使用 every { ... } returns ... 结构显式声明行为：

1. // 必须为每个需要调用的方法定义行为

2. every { myService.getData() } returns "MockedData"

3. every { myService.calculate(any()) } returns 42

AI写代码

为什么需要严格模式？

场景	严格模式	非严格模式
未定义方法调用	立即抛出异常	返回默认值（null, 0 等）
测试可靠性	确保不会意外调用未模拟的方法	可能隐藏未覆盖的依赖
测试意图	明确声明所有预期行为	隐含接受默认行为

---

典型错误示例

1. // 测试代码

2. val userService = mockk<UserService>() // 严格模式

4. // ❌ 忘记定义行为

5. userService.findUser("id123") // 抛出 MockKException!

7. // ✅ 正确做法

8. every { userService.findUser(any()) } returns User("MockedUser")

9. val result = userService.findUser("id123") // 返回 User 对象

AI写代码

严格模式的核心特点

1. 零容忍未声明行为
   任何未通过 every 定义的调用都会导致测试失败。

2. 精确控制模拟行为
   必须为每个参数组合指定行为：

   1. // 不同参数需要单独定义

   2. every { myService.parse("A") } returns 1

   3. every { myService.parse("B") } returns 2

   AI写代码

   与验证的配合
   常与 verify 一起使用确保调用符合预期：

   1. every { myService.send(any()) } returns true

   3. // 测试代码

   4. myService.send("message")

   6. verify { myService.send("message") } // 验证调用发生

   AI写代码

何时使用严格模式？

• 推荐场景

  • 需要精确控制依赖行为的测试
  • 验证复杂交互逻辑
  • 关键服务/组件的测试

• 替代方案（非严格模式）

val relaxedService = mockk<MyService>(relaxed = true)  // 允许未定义调用

AI写代码

Mock 接口、类、静态和扩展方法

• 接口/类的 mock： 对于普通的接口或类，使用 mockk<类型>() 创建 mock 对象。例如 val repo = mockk<MyRepository>()。注意 MockK 能直接 mock Kotlin 中的 final class，无需像 Mockito 那样特殊配置。也可以使用注解 @MockK 并在测试 @Before 中调用MockKAnnotations.init(this) 或使用前述的 MockKRule 进行初始化。

• Relaxed Mock： 如果不想为每个方法都定义返回值，可以创建一个 relaxed mock，即 mockk<MyClass>(relaxed = true)。这会让所有非 Unit 返回类型的方法自动返回默认值（例如布尔型为 false，引用型为 null）。这样即使不显式 stub 方法，调用时也不会抛异常。需要注意，针对泛型返回类型的函数，放宽 mock 有时可能抛出类型转换异常。

• 静态方法和顶层函数： Kotlin 的顶层函数或 Java 静态方法可以用 mockkStatic() 模拟。对于 Java 静态方法或类静态方法，直接传入类引用：

1. mockkStatic(Uri::class)

2. every { Uri.parse("http://test/path") } returns mockUri

AI写代码

这会拦截 Uri.parse() 的调用，返回自定义结果。在模拟 Kotlin 顶层（module-wide）函数或扩展函数时，可以传入生成的类名字符串（通常是包名+文件名+Kt后缀）或函数引用。例如文档中示例，将扩展函数所在文件 File.kt（包名为 pkg）中所有函数静态化：

1. mockkStatic("pkg.FileKt")

2. every { Obj(5).extensionFunc() } returns 11

AI写代码

• 如此可以模拟 Obj.extensionFunc() 的行为。总之，mockkStatic 适用于替换任何静态或顶层函数的实现，模拟完成后可用 unmockkStatic 解除。

• 对象（单例）的 mock： 对于 Kotlin 的 object 或 Java 的单例，可使用 mockkObject(SomeObject) 创建 mock 对象。此时可以像普通 mock 一样用 every { ... } 定义行为，并在测试后调用 unmockkObject(SomeObject) 恢复原状。

• 注意事项： 使用 mockkStatic 或 mockkObject 后要记得在测试结束时使用 unmockkStatic 或 unmockkObject 清理，否则可能影响后续测试。

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。