android-sunflower中的测试替身：Mock、Fake与Stub
项目地址: https://gitcode.com/gh_mirrors/an/android-sunflower 在软件开发中，测试是保证代码质量的重要环节。当我们需要测试一个组件时，往往会遇到它依赖其他组件的情况。这时，测试替身（Test Double）就派上了用场。测试替身是用来替代真实组件的对象，以便我们能够独立地测试目标组件。在android-sunflower项目中，我们可以看到Mock、Fake和Stub这三种常见测试替身的应用。
Fake：简化的真实实现
Fake是一种具有简化实现的测试替身，它通常用于替代真实的依赖组件，以便在测试环境中提供更简单、更可控的行为。在android-sunflower项目中，我们可以看到Fake的应用。
在app/src/androidTest/java/com/google/samples/apps/sunflower/data/GardenPlantingDaoTest.kt中，使用了Room的内存数据库作为Fake数据库。Room.inMemoryDatabaseBuilder创建的是一个内存中的数据库，它具有真实数据库的基本功能，但数据只存在于内存中，不会持久化到磁盘。这使得测试更加快速，并且不会对真实数据造成影响。
database = Room.inMemoryDatabaseBuilder(context, AppDatabase::class.java).build()
gardenPlantingDao = database.gardenPlantingDao()
通过使用Fake数据库，我们可以在测试中模拟数据库的各种操作，而无需依赖真实的数据库环境。
Stub：提供预设响应
Stub是一种提供预设响应的测试替身，它通常用于替代依赖组件，以便在测试中返回固定的结果。在android-sunflower项目中，我们可以看到Stub的应用。
在app/src/test/java/com/google/samples/apps/sunflower/test/CalendarMatcher.kt中，定义了一个CalendarMatcher类，它可以用来比较两个Calendar对象是否在年、月、日方面相等。这可以看作是一种Stub，它提供了固定的比较逻辑，以便在测试中验证日期相关的功能。
override fun matchesSafely(actual: Calendar?, mismatchDescription: Description?): Boolean {
if (actual == null) {
mismatchDescription?.appendText("was null")
return false
}
if (actual.get(YEAR) == expected.get(YEAR) &&
actual.get(MONTH) == expected.get(MONTH) &&
actual.get(DAY_OF_MONTH) == expected.get(DAY_OF_MONTH)
)
return true
mismatchDescription?.appendText("was ")?.appendText(formatter.format(actual.time))
return false
}
Mock：验证交互行为
Mock是一种用于验证交互行为的测试替身，它通常用于替代依赖组件，以便在测试中验证目标组件与依赖组件之间的交互是否符合预期。在android-sunflower项目中，虽然没有直接使用像Mockito这样的Mock框架，但我们可以通过一些方式模拟Mock的行为。
在app/src/androidTest/java/com/google/samples/apps/sunflower/viewmodels/PlantDetailViewModelTest.kt中，通过注入PlantRepository和GardenPlantingRepository的实例，我们可以在测试中验证ViewModel与这些仓库之间的交互。例如，在testDefaultValues测试方法中，我们验证了初始状态下isPlanted的值为false，这间接验证了ViewModel与仓库之间的交互是否正确。
@Test
@Throws(InterruptedException::class)
fun testDefaultValues() = coroutineRule.runBlockingTest {
assertFalse(viewModel.isPlanted.first())
}
总结
在android-sunflower项目中，Fake、Stub和Mock这三种测试替身都有其应用场景。Fake用于提供简化的真实实现，如内存数据库；Stub用于提供预设响应，如CalendarMatcher；Mock用于验证交互行为，如通过注入仓库实例来验证ViewModel的交互。
通过合理使用这些测试替身，我们可以编写更加可靠、独立的测试，从而提高代码质量。同时，这些测试替身的应用也展示了android-sunflower项目在测试方面的最佳实践。
在实际测试中，我们需要根据具体的测试场景选择合适的测试替身。Fake适用于需要模拟复杂依赖组件的场景，Stub适用于需要提供固定响应的场景，Mock适用于需要验证交互行为的场景。通过灵活运用这些测试替身，我们可以更好地完成测试任务，确保软件的质量。
官方文档：CONTRIBUTING.md
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
