1. 欢迎
简介
第二个测试 Codelab 主要讲解测试替身:何时在 Android 中使用它们,以及如何使用依赖注入、服务定位器模式和库来实现它们。通过这样做,您将学习如何编写:
- 资源库单元测试
- 片段和 ViewModel 集成测试
- 片段导航测试
您应该了解的内容
您应该熟悉:
- 第一个 Codelab 中介绍的测试概念:在 Android 上编写和运行单元测试,使用 JUnit、Hamcrest、AndroidX 测试、Robolectric 以及测试 LiveData
- 以下核心 Android Jetpack 库:
ViewModel
、LiveData
和导航组件 - 应用架构,遵循应用架构指南和Android 基础知识 Codelab中的模式
- Android 上协程的基础知识
您将学习的内容
- 如何规划测试策略
- 如何创建和使用测试替身,即模拟对象和存根
- 如何在 Android 中使用手动依赖注入进行单元测试和集成测试
- 如何应用服务定位器模式
- 如何测试资源库、片段、ViewModel 和导航组件
您将使用以下库和代码概念:
您将执行的操作
- 使用测试替身和依赖注入编写资源库的单元测试。
- 使用测试替身和依赖注入编写 ViewModel 的单元测试。
- 使用 Espresso UI 测试框架编写片段及其 ViewModel 的集成测试。
- 使用 Mockito 和 Espresso 编写导航测试。
2. 应用概述
在本系列 Codelab 中,您将使用 TO-DO Notes 应用。该应用允许您记下要完成的任务并将它们显示在列表中。然后,您可以将它们标记为已完成或未完成,对其进行筛选或删除它们。
此应用使用 Kotlin 编写,包含几个屏幕,使用 Jetpack 组件,并遵循应用架构指南中的架构。通过学习如何测试此应用,您将能够测试使用相同库和架构的应用。
下载代码
要开始,请下载代码:
或者,您可以克隆代码的 Github 仓库:
$ git clone https://github.com/google-developer-training/advanced-android-testing.git $ cd android-testing $ git checkout end_codelab_1
您可以在android-testing Github 仓库中浏览代码。
请花点时间熟悉代码,按照以下说明操作。
步骤 1:运行示例应用
下载 TO-DO 应用后,在 Android Studio 中打开并运行它。它应该能够编译。通过执行以下操作来浏览应用:
- 使用加号浮动操作按钮创建一个新任务。先输入标题,然后输入有关任务的其他信息。使用绿色勾号 FAB 保存它。
- 在任务列表中,点击您刚刚完成的任务的标题,然后查看该任务的详细信息屏幕以查看其余说明。
- 在列表中或详细信息屏幕上,选中该任务的复选框以将其状态设置为已完成。
- 返回任务屏幕,打开筛选菜单,按活动和已完成状态筛选任务。
- 打开导航抽屉并点击统计信息。
- 返回概述屏幕,然后从导航抽屉菜单中选择清除已完成以删除所有状态为已完成的任务。
步骤 2:浏览示例应用代码
TO-DO 应用基于架构蓝图测试和架构示例。该应用遵循应用架构指南中的架构。它使用带有片段的 ViewModel、资源库和 Room。如果您熟悉以下任何示例,则此应用具有类似的架构:
- Android Kotlin 基础知识培训 Codelab
- 高级 Android 培训 Codelab
- Room with a View Codelab
- Android 向日葵示例
- 使用 Kotlin 的 Udacity Android 应用开发培训课程
您理解应用的总体架构比深入理解任何一层中的逻辑更重要。
以下是您将找到的软件包摘要:
软件包: | ||
| 添加或编辑任务屏幕:添加或编辑任务的 UI 层代码。 | |
| 数据层:这处理任务的数据层。它包含数据库、网络和资源库代码。 | |
| 统计信息屏幕:统计信息屏幕的 UI 层代码。 | |
| 任务详细信息屏幕:单个任务的 UI 层代码。 | |
| 任务屏幕:所有任务列表的 UI 层代码。 | |
| 实用程序类:在应用的各个部分中使用的共享类,例如,用于多个屏幕上使用的滑动刷新布局。 |
数据层 (.data)
此应用包括一个模拟网络层(位于remote软件包中)和一个数据库层(位于local软件包中)。为简便起见,在此项目中,网络层使用带有延迟的HashMap
模拟,而不是发出实际的网络请求。
DefaultTasksRepository
协调或仲裁网络层和数据库层之间的关系,并返回数据到 UI 层。
UI 层 (.addedittask、.statistics、.taskdetail、.tasks)
每个 UI 层软件包都包含一个片段和一个 ViewModel,以及 UI 所需的任何其他类(例如,任务列表的适配器)。TaskActivity
是包含所有片段的活动。
导航
应用的导航由导航组件控制。它在nav_graph.xml
文件中定义。导航使用Event
类在 ViewModel 中触发;ViewModel 还确定要传递的参数。片段观察Event
并执行屏幕之间的实际导航。
3. 概念:测试策略
在本 Codelab 中,您将学习如何使用测试替身和依赖注入来测试资源库、ViewModel 和片段。在深入了解它们是什么之前,了解将指导您编写这些测试的原因和方法非常重要。
本部分介绍一些通用的测试最佳实践,因为它们适用于 Android。
测试金字塔
在考虑测试策略时,有三个相关的测试方面:
- 范围—测试接触了多少代码?测试可以在单个方法、整个应用或介于两者之间的某个位置运行。
- 速度—测试运行速度有多快?测试速度可以从毫秒到几分钟不等。
- 保真度—测试有多“真实”?例如,如果您正在测试的代码的一部分需要发出网络请求,则测试代码是否实际发出此网络请求,或者它是否模拟结果?如果测试实际与网络通信,则意味着它具有更高的保真度。权衡是测试运行时间可能更长,如果网络关闭可能会导致错误,或者使用成本可能很高。
这些方面之间存在固有的权衡。例如,速度和保真度是一种权衡——测试速度越快,保真度通常越低,反之亦然。划分自动化测试的一种常见方法是将其分为以下三类:
- 单元测试—这些是高度集中的测试,它们在一个类上运行,通常是该类中的单个方法。如果单元测试失败,您可以准确地知道代码中的问题出在哪里。它们的保真度较低,因为在现实世界中,您的应用涉及的内容远不止执行一个方法或类。它们的速度足够快,可以在每次更改代码时运行。它们最常是本地运行的测试(在
test
源代码集中)。示例:测试 ViewModel 和资源库中的单个方法。 - 集成测试—这些测试对多个类的交互进行测试,以确保它们在一起使用时按预期工作。构建集成测试的一种方法是让它们测试单个功能,例如保存任务的能力。它们测试的代码范围比单元测试更大,但仍然针对快速运行进行了优化,而不是追求完全保真度。它们可以根据情况在本地运行或作为 Instrumentation 测试运行。示例:测试单个 Fragment 和 ViewModel 对的所有功能。
- 端到端测试 (E2e)—测试多个功能协同工作的组合。它们测试应用程序的大部分内容,可以近似模拟实际使用情况,因此通常速度较慢。它们具有最高的保真度,可以告诉您应用程序作为一个整体是否正常工作。通常,这些测试将是 Instrumentation 测试(在
androidTest
源代码集中)。示例:启动整个应用程序并一起测试一些功能。
这些测试的建议比例通常用金字塔表示,其中绝大多数测试是单元测试。
架构和测试
您在测试金字塔各个层次测试应用程序的能力与您的应用程序架构密切相关。例如,架构极差的应用程序可能会将其所有逻辑都放在一个方法中。您或许可以为此编写端到端测试,因为这些测试往往会测试应用程序的大部分内容,但是编写单元测试或集成测试呢?如果所有代码都放在一个地方,就很难只测试与单个单元或功能相关的代码。
更好的方法是将应用程序逻辑分解成多个方法和类,以便可以隔离测试每个部分。架构是一种划分和组织代码的方式,可以更轻松地进行单元测试和集成测试。您将要测试的待办事项应用程序遵循特定的架构。
在本课程中,您将学习如何正确隔离地测试上述架构的各个部分。
- 首先,您将单元测试存储库。
- 然后,您将在 ViewModel 中使用测试替身,这对于单元测试和集成测试ViewModel 是必要的。
- 接下来,您将学习如何为Fragment 及其 ViewModel编写集成测试。
- 最后,您将学习如何编写包含导航组件的集成测试。
端到端测试将在下一课中介绍。
4. 任务:创建伪造数据源
当您为类的某个部分(方法或少量方法的集合)编写单元测试时,您的目标是仅测试该类中的代码。
仅测试特定类或类的代码可能很棘手。让我们来看一个例子。在 main
源代码集中打开 data.source.DefaultTasksRepository
类。这是应用程序的存储库,也是您接下来将为其编写单元测试的类。
您的目标是仅测试该类中的代码。但是,DefaultTasksRepository
依赖于其他类,例如 TasksLocalDataSource
和 TasksRemoteDataSource
才能运行。换句话说,TasksLocalDataSource
和 TasksRemoteDataSource
是 DefaultTasksRepository
的依赖项。
因此,DefaultTasksRepository
中的每个方法都会调用数据源类中的方法,而这些方法又会调用其他类中的方法来将信息保存到数据库或与网络通信。
例如,请查看 DefaultTasksRepo
中的此方法。
suspend fun getTasks(forceUpdate: Boolean = false): Result<List<Task>> {
if (forceUpdate) {
try {
updateTasksFromRemoteDataSource()
} catch (ex: Exception) {
return Result.Error(ex)
}
}
return tasksLocalDataSource.getTasks()
}
getTasks
是您可能对存储库进行的最“基本”调用之一。此方法包括从 SQLite 数据库读取和进行网络调用(对 updateTasksFromRemoteDataSource
的调用)。这涉及的代码远不止仅仅是存储库代码。
以下是一些更具体的理由,说明为什么难以测试存储库:
- 即使是对这个存储库进行最简单的测试,也需要考虑创建和管理数据库。这会引发诸如“这应该是本地测试还是 Instrumentation 测试?”以及是否应该使用 AndroidX Test 来获取模拟的 Android 环境等问题。
- 某些代码部分(例如网络代码)可能需要很长时间才能运行,或者偶尔还会失败,从而导致测试运行时间长且不稳定。
- 您的测试可能会失去诊断哪个代码导致测试失败的能力。您的测试可能会开始测试非存储库代码,例如,您的所谓“存储库”单元测试可能会因某些依赖代码(例如数据库代码)中的问题而失败。
测试替身
解决方法是,在测试存储库时,不要使用真实的网络或数据库代码,而是使用测试替身。测试替身是专门为测试而设计的类的版本。它旨在在测试中替换类的真实版本。这类似于特技替身是专门从事特技的演员,并代替真实演员进行危险动作。
以下是一些测试替身的类型:
伪造的 | 具有类“工作”实现的测试替身,但其实现方式使其适合测试但不适合生产。 |
模拟的 | 跟踪调用了哪些方法的测试替身。然后,它根据其方法是否被正确调用来通过或失败测试。 |
存根的 | 不包含任何逻辑并且只返回您编程使其返回的内容的测试替身。例如,可以对 |
虚拟的 | 传递但未使用的测试替身,例如,如果您只需要将其作为参数提供。如果您有 |
间谍的 | 还跟踪某些附加信息的测试替身;例如,如果您创建了 |
有关测试替身的更多信息,请查看厕所上的测试:了解您的测试替身。
Android 中最常用的测试替身是伪造的和模拟的。
在此任务中,您将创建一个 FakeDataSource
测试替身,以对与实际数据源分离的 DefaultTasksRepository
进行单元测试。
步骤 1:创建 FakeDataSource 类
在此步骤中,您将创建一个名为 FakeDataSouce
的类,它将是 LocalDataSource
和 RemoteDataSource
的测试替身。
- 在测试源代码集中,右键单击选择新建 -> 包。
- 创建一个data包,并在其中创建一个source包。
- 在data/source包中创建一个名为
FakeDataSource
的新类。
步骤 2:实现 TasksDataSource 接口
为了能够将新的 FakeDataSource
类用作测试替身,它必须能够替换其他数据源。这些数据源是 TasksLocalDataSource
和 TasksRemoteDataSource
。
- 请注意,这两个类都实现了
TasksDataSource
接口。
class TasksLocalDataSource internal constructor(
private val tasksDao: TasksDao,
private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO
) : TasksDataSource { ... }
object TasksRemoteDataSource : TasksDataSource { ... }
- 让
FakeDataSource
实现TasksDataSource
。
class FakeDataSource : TasksDataSource {
}
Android Studio 会提示您尚未实现 TasksDataSource
的必需方法。
- 使用快速修复菜单并选择实现成员。
- 选择所有方法,然后按确定。
步骤 3:在 FakeDataSource 中实现 getTasks 方法
FakeDataSource
是一种名为伪造的的特定类型的测试替身。伪造的测试替身具有类的“工作”实现,但其实现方式使其适合测试但不适合生产。“工作”实现意味着该类将根据输入产生逼真的输出。
例如,您的伪造数据源不会连接到网络或将任何内容保存到数据库——相反,它只会使用内存中的列表。这将在方法获取或保存任务时“按预期工作”,但您永远无法在生产中使用此实现,因为它没有保存到服务器或数据库。
一个 FakeDataSource
- 允许您测试
DefaultTasksRepository
中的代码,而无需依赖真实的数据库或网络。 - 为测试提供“足够真实”的实现。
- 更改
FakeDataSource
构造函数以创建一个名为tasks
的var
,它是一个MutableList<Task>?
,其默认值为一个空的可变列表。
class FakeDataSource(var tasks: MutableList<Task>? = mutableListOf()) : TasksDataSource { // Rest of class }
这是“伪造”数据库或服务器响应的任务列表。目前,目标是测试存储库的 getTasks
方法。这会调用数据源的 getTasks
、deleteAllTasks
和 saveTask
方法。
编写这些方法的伪造版本
- 编写
getTasks
函数:如果tasks
不为null
,则返回Success
结果;如果tasks
为null
,则返回Error
结果。 - 编写
deleteAllTasks
函数:清除可变的任务列表。 - 编写
saveTask
函数:将任务添加到列表中。
这些方法已在 FakeDataSource
中实现,代码如下所示。
override suspend fun getTasks(): Result<List<Task>> {
tasks?.let { return Success(ArrayList(it)) }
return Error(
Exception("Tasks not found")
)
}
override suspend fun deleteAllTasks() {
tasks?.clear()
}
override suspend fun saveTask(task: Task) {
tasks?.add(task)
}
如果需要,以下是导入语句
import com.example.android.architecture.blueprints.todoapp.data.Result
import com.example.android.architecture.blueprints.todoapp.data.Result.Error
import com.example.android.architecture.blueprints.todoapp.data.Result.Success
import com.example.android.architecture.blueprints.todoapp.data.Task
这与实际的本地和远程数据源的工作方式类似。
5. 任务:使用依赖注入编写测试
在此步骤中,您将使用一种称为手动依赖注入的技术,以便您可以使用刚刚创建的模拟测试对象。
主要问题是您有一个 FakeDataSource
,但尚不清楚如何在测试中使用它。它需要替换 TasksRemoteDataSource
和 TasksLocalDataSource
,但仅在测试中替换。 TasksRemoteDataSource
和 TasksLocalDataSource
都是 DefaultTasksRepository
的依赖项,这意味着 DefaultTasksRepositories
需要或“依赖”于这些类才能运行。
目前,依赖项是在 DefaultTasksRepository
的 init
方法内部构建的。
DefaultTasksRepository.kt
class DefaultTasksRepository private constructor(application: Application) {
private val tasksRemoteDataSource: TasksDataSource
private val tasksLocalDataSource: TasksDataSource
// Some other code
init {
val database = Room.databaseBuilder(application.applicationContext,
ToDoDatabase::class.java, "Tasks.db")
.build()
tasksRemoteDataSource = TasksRemoteDataSource
tasksLocalDataSource = TasksLocalDataSource(database.taskDao())
}
// Rest of class
}
由于您在 DefaultTasksRepository
内部创建和分配 taskLocalDataSource
和 tasksRemoteDataSource
,因此它们本质上是硬编码的。无法替换您的模拟测试对象。
您想要做的是提供这些数据源给类,而不是对其进行硬编码。提供依赖项称为依赖注入。有不同的方法来提供依赖项,因此也有不同类型的依赖注入。
构造函数依赖注入允许您通过将其传递到构造函数中来替换模拟测试对象。
无注入 | 注入 |
步骤 1:在 DefaultTasksRepository 中使用构造函数依赖注入
- 将
DefaultTasksRepository
的构造函数从接受Application
更改为接受两个数据源和协程调度器。
DefaultTasksRepository.kt
// REPLACE
class DefaultTasksRepository private constructor(application: Application) { // Rest of class }
// WITH
class DefaultTasksRepository(
private val tasksRemoteDataSource: TasksDataSource,
private val tasksLocalDataSource: TasksDataSource,
private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO) { // Rest of class }
- 因为您已经传入依赖项,所以删除
init
方法。您不再需要创建依赖项。 - 还要删除旧的实例变量。您将在构造函数中定义它们。
DefaultTasksRepository.kt
// Delete these old variables
private val tasksRemoteDataSource: TasksDataSource
private val tasksLocalDataSource: TasksDataSource
private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO
- 最后,更新
getRepository
方法以使用新的构造函数
DefaultTasksRepository.kt
companion object {
@Volatile
private var INSTANCE: DefaultTasksRepository? = null
fun getRepository(app: Application): DefaultTasksRepository {
return INSTANCE ?: synchronized(this) {
val database = Room.databaseBuilder(app,
ToDoDatabase::class.java, "Tasks.db")
.build()
DefaultTasksRepository(TasksRemoteDataSource, TasksLocalDataSource(database.taskDao())).also {
INSTANCE = it
}
}
}
}
您现在正在使用构造函数依赖注入!
步骤 2:在测试中使用您的 FakeDataSource
现在您的代码使用了构造函数依赖注入,您可以使用模拟数据源来测试您的 DefaultTasksRepository
。
- 右键单击
DefaultTasksRepository
类名,然后选择 **生成**,然后选择 **测试**。 - 按照提示在 **test** 源集中创建
DefaultTasksRepositoryTest
。 - 在新的
DefaultTasksRepositoryTest
类顶部,添加以下成员变量以表示模拟数据源中的数据。
DefaultTasksRepositoryTest.kt
private val task1 = Task("Title1", "Description1")
private val task2 = Task("Title2", "Description2")
private val task3 = Task("Title3", "Description3")
private val remoteTasks = listOf(task1, task2).sortedBy { it.id }
private val localTasks = listOf(task3).sortedBy { it.id }
private val newTasks = listOf(task3).sortedBy { it.id }
- 创建三个变量,两个
FakeDataSource
成员变量(每个存储库的数据源一个)和一个DefaultTasksRepository
变量,您将对其进行测试。
DefaultTasksRepositoryTest.kt
private lateinit var tasksRemoteDataSource: FakeDataSource
private lateinit var tasksLocalDataSource: FakeDataSource
// Class under test
private lateinit var tasksRepository: DefaultTasksRepository
创建一个方法来设置和初始化可测试的 DefaultTasksRepository
。这个 DefaultTasksRepository
将使用您的模拟测试对象 FakeDataSource
。
- 创建一个名为
createRepository
的方法,并使用@Before
注解它。 - 使用
remoteTasks
和localTasks
列表实例化模拟数据源。 - 使用您刚刚创建的两个模拟数据源和
Dispatchers.Unconfined
实例化您的tasksRepository
。
最终方法应如下所示。
DefaultTasksRepositoryTest.kt
@Before
fun createRepository() {
tasksRemoteDataSource = FakeDataSource(remoteTasks.toMutableList())
tasksLocalDataSource = FakeDataSource(localTasks.toMutableList())
// Get a reference to the class under test
tasksRepository = DefaultTasksRepository(
// TODO Dispatchers.Unconfined should be replaced with Dispatchers.Main
// this requires understanding more about coroutines + testing
// so we will keep this as Unconfined for now.
tasksRemoteDataSource, tasksLocalDataSource, Dispatchers.Unconfined
)
}
步骤 3:编写 DefaultTasksRepository getTasks() 测试
是时候编写 DefaultTasksRepository
测试了!
- 为存储库的
getTasks
方法编写测试。检查当您使用true
调用getTasks
(意味着它应该从远程数据源重新加载)时,它是否返回来自远程数据源(而不是本地数据源)的数据。
DefaultTasksRepositoryTest.kt
@Test
fun getTasks_requestsAllTasksFromRemoteDataSource(){
// When tasks are requested from the tasks repository
val tasks = tasksRepository.getTasks(true) as Success
// Then tasks are loaded from the remote data source
assertThat(tasks.data, IsEqual(remoteTasks))
}
调用时会出现错误
getTasks
步骤 4:添加 runBlockingTest
协程错误是预期的,因为 getTasks
是一个 suspend
函数,您需要启动一个协程来调用它。为此,您需要一个协程作用域。为了解决此错误,您需要添加一些 Gradle 依赖项来处理在测试中启动协程。
- 通过使用 **
testImplementation
** 将测试协程所需的依赖项添加到测试源集中。
app/build.gradle
testImplementation "org.jetbrains.kotlinx:kotlinx-coroutines-test:$coroutinesVersion"
别忘了同步!
kotlinx-coroutines-test
是协程测试库,专门用于测试协程。要运行测试,请使用函数runBlockingTest
。这是协程测试库提供的函数。它接收一段代码块,然后在此代码块中在一个特殊的协程上下文中运行,该上下文同步且立即运行,这意味着操作将以确定性顺序发生。这实际上使您的协程像非协程一样运行,因此它用于测试代码。
在调用 suspend
函数时,在测试类中使用 runBlockingTest
。您将在本系列的下一个代码实验室中了解有关 runBlockingTest
的工作方式以及如何测试协程的更多信息。
- 在类上方添加
@ExperimentalCoroutinesApi
。这表示您知道您正在类中使用实验性协程 API(runBlockingTest
)。如果没有它,您将收到警告。 - 回到您的
DefaultTasksRepositoryTest
中,添加runBlockingTest
,以便它将您的整个测试作为“代码块”接收。
最终测试如下所示。
DefaultTasksRepositoryTest.kt
import com.example.android.architecture.blueprints.todoapp.data.Result.Success
import com.example.android.architecture.blueprints.todoapp.data.Task
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.ExperimentalCoroutinesApi
import kotlinx.coroutines.test.runBlockingTest
import org.hamcrest.core.IsEqual
import org.junit.Assert.*
import org.junit.Before
import org.junit.Test
@ExperimentalCoroutinesApi
class DefaultTasksRepositoryTest {
private val task1 = Task("Title1", "Description1")
private val task2 = Task("Title2", "Description2")
private val task3 = Task("Title3", "Description3")
private val remoteTasks = listOf(task1, task2).sortedBy { it.id }
private val localTasks = listOf(task3).sortedBy { it.id }
private val newTasks = listOf(task3).sortedBy { it.id }
private lateinit var tasksRemoteDataSource: FakeDataSource
private lateinit var tasksLocalDataSource: FakeDataSource
// Class under test
private lateinit var tasksRepository: DefaultTasksRepository
@Before
fun createRepository() {
tasksRemoteDataSource = FakeDataSource(remoteTasks.toMutableList())
tasksLocalDataSource = FakeDataSource(localTasks.toMutableList())
// Get a reference to the class under test
tasksRepository = DefaultTasksRepository(
// TODO Dispatchers.Unconfined should be replaced with Dispatchers.Main
// this requires understanding more about coroutines + testing
// so we will keep this as Unconfined for now.
tasksRemoteDataSource, tasksLocalDataSource, Dispatchers.Unconfined
)
}
@Test
fun getTasks_requestsAllTasksFromRemoteDataSource() = runBlockingTest {
// When tasks are requested from the tasks repository
val tasks = tasksRepository.getTasks(true) as Success
// Then tasks are loaded from the remote data source
assertThat(tasks.data, IsEqual(remoteTasks))
}
}
- 运行新的
getTasks_requestsAllTasksFromRemoteDataSource
测试并确认它有效且错误已消失!
6. 任务:设置模拟存储库
您刚刚了解了如何对存储库进行单元测试。在接下来的步骤中,您将再次使用依赖注入并创建另一个模拟测试对象——这次是为了展示如何为您的视图模型编写单元测试和集成测试。
单元测试应该仅测试您感兴趣的类或方法。这被称为在**隔离**状态下进行测试,您可以在其中清楚地隔离您的“单元”并且只测试属于该单元的代码。
因此,TasksViewModelTest
应该只测试 TasksViewModel
代码——它不应该测试数据库、网络或存储库类中的代码。因此,对于您的视图模型,就像您刚刚对存储库所做的那样,您将创建一个模拟存储库并应用依赖注入以在测试中使用它。
在此任务中,您将依赖注入应用于视图模型。
步骤 1. 创建 TasksRepository 接口
使用构造函数依赖注入的第一步是创建模拟类和真实类之间共享的公共接口。
这在实践中是如何实现的?查看 TasksRemoteDataSource
、TasksLocalDataSource
和 FakeDataSource
,并注意它们都共享相同的接口:TasksDataSource
。这允许您在 DefaultTasksRepository
的构造函数中声明您接收 TasksDataSource
。
DefaultTasksRepository.kt
class DefaultTasksRepository(
private val tasksRemoteDataSource: TasksDataSource,
private val tasksLocalDataSource: TasksDataSource,
private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO) {
这就是我们能够替换您的 FakeDataSource
的原因!
接下来,为 DefaultTasksRepository
创建一个接口,就像您为数据源所做的那样。它需要包含 DefaultTasksRepository
的所有公共方法(公共 API 表面)。
- 打开
DefaultTasksRepository
并右键单击类名。然后选择 **重构 -> 抽取 -> 接口**。
- 选择 **抽取到单独的文件**。
- 在 **抽取接口** 窗口中,将接口名称更改为
TasksRepository
。 - 在 **构成接口的成员** 部分,选中除两个伴生成员和 **私有** 方法之外的所有成员。
- 单击 **重构**。新的
TasksRepository
接口应该出现在 **data/source** 包中。
并且 DefaultTasksRepository
现在实现了 TasksRepository
接口。
- 运行您的应用(非测试),确保一切正常。
步骤 2. 创建 FakeTestRepository
现在您有了接口,您可以创建 DefaultTasksRepository
的测试替身。
- 在测试源代码集中,在data/source目录下创建 Kotlin 文件和类
FakeTestRepository.kt
,并继承自TasksRepository
接口。
FakeTestRepository.kt
class FakeTestRepository : TasksRepository {
}
系统会提示您需要实现接口方法。
- 将鼠标悬停在错误上,直到出现建议菜单,然后单击并选择实现成员。
- 选择所有方法,然后按确定。
步骤 3. 实现 FakeTestRepository 方法
现在您拥有一个 FakeTestRepository
类,其中包含“未实现”的方法。与实现 FakeDataSource
的方式类似,FakeTestRepository
将由数据结构支持,而不是处理本地和远程数据源之间的复杂中介。
请注意,您的 FakeTestRepository
不需要使用 FakeDataSource
或类似的东西;它只需要根据输入返回逼真的虚假输出。您将使用 LinkedHashMap
存储任务列表,并使用 MutableLiveData
存储可观察的任务。
- 在
FakeTestRepository
中,添加一个LinkedHashMap
变量来表示当前的任务列表,并添加一个MutableLiveData
来存储可观察的任务。
FakeTestRepository.kt
class FakeTestRepository : TasksRepository {
var tasksServiceData: LinkedHashMap<String, Task> = LinkedHashMap()
private val observableTasks = MutableLiveData<Result<List<Task>>>()
// Rest of class
}
实现以下方法
getTasks
—此方法应获取tasksServiceData
并使用tasksServiceData.values.toList()
将其转换为列表,然后将其作为Success
结果返回。refreshTasks
—将observableTasks
的值更新为getTasks()
返回的值。observeTasks
—使用runBlocking
创建一个协程并运行refreshTasks
,然后返回observableTasks
。
对于您的测试替身,请使用 runBlocking
。runBlocking
更接近于仓库的“真实”实现的行为模拟,并且对于模拟对象来说更可取,这样它们的行为更接近于真实实现。
在测试类中(即包含 @Test
函数的类),使用 runBlockingTest
以获得确定性行为。
以下是这些方法的代码。
FakeTestRepository.kt
class FakeTestRepository : TasksRepository {
var tasksServiceData: LinkedHashMap<String, Task> = LinkedHashMap()
private val observableTasks = MutableLiveData<Result<List<Task>>>()
override suspend fun getTasks(forceUpdate: Boolean): Result<List<Task>> {
return Result.Success(tasksServiceData.values.toList())
}
override suspend fun refreshTasks() {
observableTasks.value = getTasks()
}
override fun observeTasks(): LiveData<Result<List<Task>>> {
runBlocking { refreshTasks() }
return observableTasks
}
override suspend fun completeTask(task: Task) {
val completedTask = task.copy(isCompleted = true)
tasksServiceData[task.id] = completedTask
refreshTasks()
}
// Rest of class
}
步骤 4. 添加用于测试 addTasks 的方法
在测试时,最好在您的存储库中已经有某些 Tasks
。您可以多次调用 saveTask
,但为了简化此过程,请添加一个专门用于测试的辅助方法,让您可以添加任务。
- 添加
addTasks
方法,该方法接受vararg
任务,将每个任务添加到HashMap
中,然后刷新任务。
FakeTestRepository.kt
fun addTasks(vararg tasks: Task) {
for (task in tasks) {
tasksServiceData[task.id] = task
}
runBlocking { refreshTasks() }
}
此时,您拥有一个用于测试的模拟存储库,并实现了一些关键方法。接下来,在您的测试中使用它!
7. 任务:在 ViewModel 中使用模拟存储库
在此任务中,您将在 ViewModel
中使用模拟类。使用构造函数依赖注入,通过向 TasksViewModel
的构造函数添加 TasksRepository
变量来通过构造函数依赖注入传入两个数据源。
此过程在视图模型中略有不同,因为您不会直接构造它们。例如
class TasksFragment : Fragment() {
private val viewModel by viewModels<TasksViewModel>()
// Rest of class...
}
如上面的代码所示,您正在使用 viewModel
的 属性委托 来创建视图模型。要更改视图模型的构造方式,您需要添加和使用 ViewModelProvider.Factory
。如果您不熟悉 ViewModelProvider.Factory
,您可以在这里了解更多信息。
步骤 1. 在 TasksViewModel 中创建和使用 ViewModelFactory
您首先要更新与 Tasks
屏幕相关的类和测试。
- 打开
TasksViewModel
。 - 更改
TasksViewModel
的构造函数,使其接收TasksRepository
,而不是在类内构造它。
TasksViewModel.kt
// REPLACE
class TasksViewModel(application: Application) : AndroidViewModel(application) {
private val tasksRepository = DefaultTasksRepository.getRepository(application)
// Rest of class
}
// WITH
class TasksViewModel( private val tasksRepository: TasksRepository ) : ViewModel() {
// Rest of class
}
由于您更改了构造函数,因此现在需要使用工厂来构造 TasksViewModel
。为了方便起见,您可以将工厂类放在与 TasksViewModel
相同的文件中,但您也可以将其放在自己的文件中。
- 在
TasksViewModel
文件的底部,在类之外,添加一个TasksViewModelFactory
,该工厂接收一个普通的TasksRepository
。
TasksViewModel.kt
@Suppress("UNCHECKED_CAST")
class TasksViewModelFactory (
private val tasksRepository: TasksRepository
) : ViewModelProvider.NewInstanceFactory() {
override fun <T : ViewModel> create(modelClass: Class<T>) =
(TasksViewModel(tasksRepository) as T)
}
这是更改 ViewModel
构造方式的标准方法。现在您有了工厂,请在您构造视图模型的任何地方使用它。
- 更新
TasksFragment
以使用工厂。
TasksFragment.kt
// REPLACE
private val viewModel by viewModels<TasksViewModel>()
// WITH
private val viewModel by viewModels<TasksViewModel> {
TasksViewModelFactory(DefaultTasksRepository.getRepository(requireActivity().application))
}
- 运行您的应用代码,并确保一切正常!
步骤 2. 在 TasksViewModelTest 中使用 FakeTestRepository
现在,您可以使用模拟存储库而不是在视图模型测试中使用真实的存储库。
- 打开
TasksViewModelTest
。它位于测试源代码集中的tasks文件夹下。 - 在
TasksViewModelTest
中添加一个FakeTestRepository
属性。
TaskViewModelTest.kt
@RunWith(AndroidJUnit4::class)
class TasksViewModelTest {
// Use a fake repository to be injected into the viewmodel
private lateinit var tasksRepository: FakeTestRepository
// Rest of class
}
- 更新
setupViewModel
方法以创建具有三个任务的FakeTestRepository
,然后使用此存储库构造tasksViewModel
。
TasksViewModelTest.kt
@Before
fun setupViewModel() {
// We initialise the tasks to 3, with one active and two completed
tasksRepository = FakeTestRepository()
val task1 = Task("Title1", "Description1")
val task2 = Task("Title2", "Description2", true)
val task3 = Task("Title3", "Description3", true)
tasksRepository.addTasks(task1, task2, task3)
tasksViewModel = TasksViewModel(tasksRepository)
}
- 由于您不再使用 AndroidX Test
ApplicationProvider.getApplicationContext
代码,您还可以删除@RunWith(AndroidJUnit4::class)
注解。 - 运行您的测试,确保它们都能正常工作!
通过使用构造函数依赖注入,您现在已经删除了 DefaultTasksRepository
作为依赖项,并在测试中将其替换为 FakeTestRepository
。
步骤 3. 还更新 TaskDetailFragment 和 ViewModel
对 TaskDetailFragment
和 TaskDetailViewModel
进行相同的更改。这将为以后编写 TaskDetail
测试做准备。
- 打开
TaskDetailViewModel
。 - 更新构造函数
TaskDetailViewModel.kt
// REPLACE
class TaskDetailViewModel(application: Application) : AndroidViewModel(application) {
private val tasksRepository = DefaultTasksRepository.getRepository(application)
// Rest of class
}
// WITH
class TaskDetailViewModel(
private val tasksRepository: TasksRepository
) : ViewModel() { // Rest of class }
- 在
TaskDetailViewModel
文件的底部,在类之外,添加一个TaskDetailViewModelFactory
。
TaskDetailViewModel.kt
@Suppress("UNCHECKED_CAST")
class TaskDetailViewModelFactory (
private val tasksRepository: TasksRepository
) : ViewModelProvider.NewInstanceFactory() {
override fun <T : ViewModel> create(modelClass: Class<T>) =
(TaskDetailViewModel(tasksRepository) as T)
}
- 更新
TaskDetailFragment
以使用工厂。
TaskDetailFragment.kt
// REPLACE
private val viewModel by viewModels<TaskDetailViewModel>()
// WITH
private val viewModel by viewModels<TaskDetailViewModel> {
TaskDetailViewModelFactory(DefaultTasksRepository.getRepository(requireActivity().application))
}
- 运行您的代码,确保一切正常。
您现在可以使用 FakeTestRepository
来代替 TasksFragment
和 TaskDetailFragment
中的真实存储库。
8. 任务:从测试启动片段
接下来,您将编写集成测试以测试片段和视图模型的交互。您将找出视图模型代码是否适当地更新了您的 UI。为此,您将使用
- ServiceLocator 模式
- Espresso 和 Mockito 库
集成测试测试多个类的交互,以确保它们一起使用时能够按预期工作。这些测试可以在本地(test
源代码集)或作为 Instrumentation 测试(androidTest
源代码集)运行。
在您的情况下,您将针对每个片段编写集成测试,以测试片段和视图模型,从而测试片段的主要功能。
步骤 1. 添加 Gradle 依赖项
- 添加以下 Gradle 依赖项。
app/build.gradle
// Dependencies for Android instrumented unit tests
androidTestImplementation "junit:junit:$junitVersion"
androidTestImplementation "org.jetbrains.kotlinx:kotlinx-coroutines-test:$coroutinesVersion"
// Testing code should not be included in the main code.
// Once https://issuetracker.google.com/128612536 is fixed this can be fixed.
implementation "androidx.fragment:fragment-testing:$fragmentVersion"
implementation "androidx.test:core:$androidXTestCoreVersion"
这些依赖项包括
junit:junit
—JUnit,编写基本测试语句所必需。androidx.test:core
—核心 AndroidX 测试库kotlinx-coroutines-test
—协程测试库androidx.fragment:fragment-testing
—AndroidX 测试库,用于在测试中创建片段并更改其状态。
由于您将在 androidTest
源代码集中使用这些库,因此使用 androidTestImplementation
将它们添加为依赖项。
步骤 2. 创建 TaskDetailFragmentTest 类
TaskDetailFragment
显示单个任务的信息。
首先,你将为TaskDetailFragment
编写一个片段测试,因为它与其他片段相比,功能比较基本。
- 打开
taskdetail.TaskDetailFragment
。 - 生成
TaskDetailFragment
的测试,就像你之前做的那样。接受默认选项,并将其放在androidTest源代码集中(而不是test
源代码集中)。
- 将以下注解添加到
TaskDetailFragmentTest
类。
TaskDetailFragmentTest.kt
@MediumTest
@RunWith(AndroidJUnit4::class)
class TaskDetailFragmentTest {
}
这些注解的目的是:
@MediumTest
——将测试标记为“中等运行时间”集成测试(相对于@SmallTest
单元测试和@LargeTest
端到端测试)。这有助于你对测试进行分组并选择要运行的测试大小。@RunWith(AndroidJUnit4::class)
——用于任何使用 AndroidX Test 的类。
步骤 3. 从测试中启动片段
在此任务中,你将使用AndroidX 测试库启动TaskDetailFragment
。FragmentScenario
是 AndroidX Test 中的一个类,它围绕片段进行封装,并为你提供对片段生命周期的直接控制以进行测试。要为片段编写测试,你需要为要测试的片段(TaskDetailFragment
)创建一个FragmentScenario
。
- 复制此测试到
TaskDetailFragmentTest
。
TaskDetailFragmentTest.kt
@Test
fun activeTaskDetails_DisplayedInUi() {
// GIVEN - Add active (incomplete) task to the DB
val activeTask = Task("Active Task", "AndroidX Rocks", false)
// WHEN - Details fragment launched to display task
val bundle = TaskDetailFragmentArgs(activeTask.id).toBundle()
launchFragmentInContainer<TaskDetailFragment>(bundle, R.style.AppTheme)
}
上面的代码:
- 创建一个任务。
- 创建一个
Bundle
,它表示传递到片段的任务的片段参数。 launchFragmentInContainer
函数使用此捆绑包和主题创建一个FragmentScenario
。
这还不是一个完整的测试,因为它没有断言任何内容。现在,运行测试并观察会发生什么。
- 这是一个已安装的测试,因此请确保模拟器或你的设备可见。
- 运行测试。
应该会发生一些事情。
- 首先,因为这是一个已安装的测试,所以测试将在你的物理设备(如果已连接)或模拟器上运行。
- 它应该启动片段。
- 注意它如何不导航到任何其他片段或没有任何与活动相关的菜单 - 它只是片段。
最后,仔细观察并注意片段显示“无数据”,因为它没有成功加载任务数据。
你的测试既需要加载TaskDetailFragment
(你已经完成了),又需要断言数据已正确加载。为什么没有数据?这是因为你创建了一个任务,但你没有将其保存到存储库。
@Test
fun activeTaskDetails_DisplayedInUi() {
// This DOES NOT save the task anywhere
val activeTask = Task("Active Task", "AndroidX Rocks", false)
val bundle = TaskDetailFragmentArgs(activeTask.id).toBundle()
launchFragmentInContainer<TaskDetailFragment>(bundle, R.style.AppTheme)
}
你拥有这个FakeTestRepository
,但是你需要某种方法将你的真实存储库替换为你的片段的伪造存储库。你将在下一步完成此操作!
9. 任务:创建 ServiceLocator
在此任务中,你将使用ServiceLocator
将伪造的存储库提供给你的片段。这将允许你编写片段和视图模型集成测试。
你不能在这里使用构造函数依赖注入,就像你之前那样,当你需要向视图模型或存储库提供依赖项时。构造函数依赖注入要求你 *构造* 类。片段和活动是你不会构造并且通常无法访问其构造函数的类的示例。
由于你没有构造片段,因此你不能使用构造函数依赖注入来将存储库测试替身(FakeTestRepository
)交换到片段。相反,使用服务定位器模式。服务定位器模式是依赖注入的替代方案。它涉及创建一个名为“服务定位器”的单例类,其目的是为常规代码和测试代码提供依赖项。在常规应用程序代码(main
源代码集)中,所有这些依赖项都是常规应用程序依赖项。对于测试,你修改服务定位器以提供依赖项的测试替身版本。
不使用服务定位器 | 使用服务定位器 |
对于此 codelab 应用,请执行以下操作:
- 创建一个 ServiceLocator 类,该类能够构造和存储存储库。默认情况下,它构造一个“普通”存储库。
- 重构你的代码,以便当你需要存储库时,使用 ServiceLocator。
- 在你的测试类中,调用 ServiceLocator 上的一个方法,该方法将“普通”存储库替换为你的测试替身。
步骤 1. 创建 ServiceLocator
让我们创建一个ServiceLocator
类。它将与其余应用程序代码一起位于主源代码集中,因为它由主应用程序代码使用。
注意:ServiceLocator
是一个单例,因此请对该类使用Kotlin object
关键字。
- 在主源代码集的顶层创建文件ServiceLocator.kt。
- 定义一个名为
ServiceLocator
的object
。 - 创建
database
和repository
实例变量,并将两者都设置为null
。 - 使用
@Volatile
注解存储库,因为它可能被多个线程使用(@Volatile
的详细解释在这里)。
你的代码应如下所示。
object ServiceLocator {
private var database: ToDoDatabase? = null
@Volatile
var tasksRepository: TasksRepository? = null
}
目前,你的ServiceLocator
唯一需要做的就是知道如何返回TasksRepository
。它将返回一个预先存在的DefaultTasksRepository
,或者根据需要创建并返回一个新的DefaultTasksRepository
。
定义以下函数:
provideTasksRepository
——提供已存在的存储库或创建一个新的存储库。此方法应在this
上synchronized
,以避免在多个线程运行的情况下意外创建两个存储库实例。createTasksRepository
——创建新存储库的代码。将调用createTaskLocalDataSource
并创建一个新的TasksRemoteDataSource
。createTaskLocalDataSource
——创建新的本地数据源的代码。将调用createDataBase
。createDataBase
——创建新数据库的代码。
完整的代码如下所示。
ServiceLocator.kt
object ServiceLocator {
private var database: ToDoDatabase? = null
@Volatile
var tasksRepository: TasksRepository? = null
fun provideTasksRepository(context: Context): TasksRepository {
synchronized(this) {
return tasksRepository ?: createTasksRepository(context)
}
}
private fun createTasksRepository(context: Context): TasksRepository {
val newRepo = DefaultTasksRepository(TasksRemoteDataSource, createTaskLocalDataSource(context))
tasksRepository = newRepo
return newRepo
}
private fun createTaskLocalDataSource(context: Context): TasksDataSource {
val database = database ?: createDataBase(context)
return TasksLocalDataSource(database.taskDao())
}
private fun createDataBase(context: Context): ToDoDatabase {
val result = Room.databaseBuilder(
context.applicationContext,
ToDoDatabase::class.java, "Tasks.db"
).build()
database = result
return result
}
}
步骤 2. 在应用程序中使用 ServiceLocator
你将更改你的主应用程序代码(而不是你的测试),以便在一个地方(你的ServiceLocator
)创建存储库。
务必只创建存储库类的单个实例。为确保这一点,你将在 TodoApplication 类中使用服务定位器。
- 在包层次结构的顶层,打开
TodoApplication
并为你的存储库创建一个val
,并为其分配使用ServiceLocator.provideTaskRepository
获得的存储库。
TodoApplication.kt
class TodoApplication : Application() {
val taskRepository: TasksRepository
get() = ServiceLocator.provideTasksRepository(this)
override fun onCreate() {
super.onCreate()
if (BuildConfig.DEBUG) Timber.plant(DebugTree())
}
}
现在你已经在应用程序中创建了一个存储库,你可以删除DefaultTasksRepository
中的旧getRepository
方法。
- 打开
DefaultTasksRepository
并删除伴生对象。
DefaultTasksRepository.kt
// DELETE THIS COMPANION OBJECT
companion object {
@Volatile
private var INSTANCE: DefaultTasksRepository? = null
fun getRepository(app: Application): DefaultTasksRepository {
return INSTANCE ?: synchronized(this) {
val database = Room.databaseBuilder(app,
ToDoDatabase::class.java, "Tasks.db")
.build()
DefaultTasksRepository(TasksRemoteDataSource, TasksLocalDataSource(database.taskDao())).also {
INSTANCE = it
}
}
}
}
现在,在所有使用getRepository
的地方,都使用应用程序的taskRepository
代替。这确保了你不是直接创建存储库,而是获取ServiceLocator
提供的任何存储库。
- 打开
TaskDetailFragement
并找到类顶部的getRepository
调用。 - 将此调用替换为从
TodoApplication
获取存储库的调用。
TaskDetailFragment.kt
// REPLACE this code
private val viewModel by viewModels<TaskDetailViewModel> {
TaskDetailViewModelFactory(DefaultTasksRepository.getRepository(requireActivity().application))
}
// WITH this code
private val viewModel by viewModels<TaskDetailViewModel> {
TaskDetailViewModelFactory((requireContext().applicationContext as TodoApplication).taskRepository)
}
- 对
TasksFragment
执行相同的操作。
TasksFragment.kt
// REPLACE this code
private val viewModel by viewModels<TasksViewModel> {
TasksViewModelFactory(DefaultTasksRepository.getRepository(requireActivity().application))
}
// WITH this code
private val viewModel by viewModels<TasksViewModel> {
TasksViewModelFactory((requireContext().applicationContext as TodoApplication).taskRepository)
}
- 对于
StatisticsViewModel
和AddEditTaskViewModel
,更新获取资源库的代码,以便使用来自TodoApplication
的资源库。
// REPLACE this code
private val tasksRepository = DefaultTasksRepository.getRepository(application)
// WITH this code
private val tasksRepository = (application as TodoApplication).taskRepository
- 运行您的应用程序(不是测试)!
由于您只是重构了代码,因此应用程序应该能够正常运行,没有任何问题。
步骤 3. 创建 FakeAndroidTestRepository
您已经在测试源集中拥有一个 FakeTestRepository
。默认情况下,您无法在 test
和 androidTest
源集之间共享测试类。因此,您需要在 androidTest
源集中创建一个 FakeTestRepository
类的副本,并将其命名为 FakeAndroidTestRepository
。
- 右键单击
androidTest
源集并创建一个 **data.source** 包。 - 在此源包中创建一个名为
FakeAndroidTestRepository.kt
的新类。 - 将以下代码复制到该类中。
FakeAndroidTestRepository.kt
import androidx.annotation.VisibleForTesting
import androidx.lifecycle.LiveData
import androidx.lifecycle.MutableLiveData
import androidx.lifecycle.map
import com.example.android.architecture.blueprints.todoapp.data.Result
import com.example.android.architecture.blueprints.todoapp.data.Result.Error
import com.example.android.architecture.blueprints.todoapp.data.Result.Success
import com.example.android.architecture.blueprints.todoapp.data.Task
import kotlinx.coroutines.runBlocking
import java.util.LinkedHashMap
class FakeAndroidTestRepository : TasksRepository {
var tasksServiceData: LinkedHashMap<String, Task> = LinkedHashMap()
private var shouldReturnError = false
private val observableTasks = MutableLiveData<Result<List<Task>>>()
fun setReturnError(value: Boolean) {
shouldReturnError = value
}
override suspend fun refreshTasks() {
observableTasks.value = getTasks()
}
override suspend fun refreshTask(taskId: String) {
refreshTasks()
}
override fun observeTasks(): LiveData<Result<List<Task>>> {
runBlocking { refreshTasks() }
return observableTasks
}
override fun observeTask(taskId: String): LiveData<Result<Task>> {
runBlocking { refreshTasks() }
return observableTasks.map { tasks ->
when (tasks) {
is Result.Loading -> Result.Loading
is Error -> Error(tasks.exception)
is Success -> {
val task = tasks.data.firstOrNull() { it.id == taskId }
?: return@map Error(Exception("Not found"))
Success(task)
}
}
}
}
override suspend fun getTask(taskId: String, forceUpdate: Boolean): Result<Task> {
if (shouldReturnError) {
return Error(Exception("Test exception"))
}
tasksServiceData[taskId]?.let {
return Success(it)
}
return Error(Exception("Could not find task"))
}
override suspend fun getTasks(forceUpdate: Boolean): Result<List<Task>> {
if (shouldReturnError) {
return Error(Exception("Test exception"))
}
return Success(tasksServiceData.values.toList())
}
override suspend fun saveTask(task: Task) {
tasksServiceData[task.id] = task
}
override suspend fun completeTask(task: Task) {
val completedTask = Task(task.title, task.description, true, task.id)
tasksServiceData[task.id] = completedTask
}
override suspend fun completeTask(taskId: String) {
// Not required for the remote data source.
throw NotImplementedError()
}
override suspend fun activateTask(task: Task) {
val activeTask = Task(task.title, task.description, false, task.id)
tasksServiceData[task.id] = activeTask
}
override suspend fun activateTask(taskId: String) {
throw NotImplementedError()
}
override suspend fun clearCompletedTasks() {
tasksServiceData = tasksServiceData.filterValues {
!it.isCompleted
} as LinkedHashMap<String, Task>
}
override suspend fun deleteTask(taskId: String) {
tasksServiceData.remove(taskId)
refreshTasks()
}
override suspend fun deleteAllTasks() {
tasksServiceData.clear()
refreshTasks()
}
fun addTasks(vararg tasks: Task) {
for (task in tasks) {
tasksServiceData[task.id] = task
}
runBlocking { refreshTasks() }
}
}
步骤 4. 为测试准备您的 ServiceLocator
好的,现在是时候使用 ServiceLocator
在测试时替换测试替身了。为此,您需要向 ServiceLocator
代码中添加一些代码。
- 打开
ServiceLocator.kt
。 - 将
tasksRepository
的 setter 标记为@VisibleForTesting
。此注解是一种表达 setter 为公共的原因是为了进行测试的方法。
ServiceLocator.kt
@Volatile
var tasksRepository: TasksRepository? = null
@VisibleForTesting set
无论您单独运行测试还是成组运行测试,您的测试都应该以完全相同的方式运行。这意味着您的测试不应具有相互依赖的行为(这意味着避免在测试之间共享对象)。
由于 ServiceLocator
是一个单例,因此它有可能在测试之间意外共享。为了避免这种情况,请创建一个方法,以便在测试之间正确重置 ServiceLocator
的状态。
- 添加一个名为
lock
的实例变量,其值为Any
。
ServiceLocator.kt
private val lock = Any()
- 添加一个特定于测试的方法,名为
resetRepository
,它清除数据库并将资源库和数据库都设置为 null。
ServiceLocator.kt
@VisibleForTesting
fun resetRepository() {
synchronized(lock) {
runBlocking {
TasksRemoteDataSource.deleteAllTasks()
}
// Clear all data to avoid test pollution.
database?.apply {
clearAllTables()
close()
}
database = null
tasksRepository = null
}
}
步骤 5. 使用您的 ServiceLocator
在此步骤中,您将使用 ServiceLocator
。
- 打开
TaskDetailFragmentTest
。 - 声明一个
lateinit TasksRepository
变量。 - 添加一个设置方法和一个拆卸方法,以便在每次测试之前设置
FakeAndroidTestRepository
,并在每次测试之后将其清理。
TaskDetailFragmentTest.kt
private lateinit var repository: TasksRepository
@Before
fun initRepository() {
repository = FakeAndroidTestRepository()
ServiceLocator.tasksRepository = repository
}
@After
fun cleanupDb() = runBlockingTest {
ServiceLocator.resetRepository()
}
- 将
activeTaskDetails_DisplayedInUi()
函数体包装在runBlockingTest
中。 - 在启动片段之前,将
activeTask
保存到资源库中。
repository.saveTask(activeTask)
最终测试如下面的代码所示。
TaskDetailFragmentTest.kt
@Test
fun activeTaskDetails_DisplayedInUi() = runBlockingTest{
// GIVEN - Add active (incomplete) task to the DB
val activeTask = Task("Active Task", "AndroidX Rocks", false)
repository.saveTask(activeTask)
// WHEN - Details fragment launched to display task
val bundle = TaskDetailFragmentArgs(activeTask.id).toBundle()
launchFragmentInContainer<TaskDetailFragment>(bundle, R.style.AppTheme)
}
- 使用
@ExperimentalCoroutinesApi
注解整个类。
完成后,代码将如下所示。
TaskDetailFragmentTest.kt
@MediumTest
@ExperimentalCoroutinesApi
@RunWith(AndroidJUnit4::class)
class TaskDetailFragmentTest {
private lateinit var repository: TasksRepository
@Before
fun initRepository() {
repository = FakeAndroidTestRepository()
ServiceLocator.tasksRepository = repository
}
@After
fun cleanupDb() = runBlockingTest {
ServiceLocator.resetRepository()
}
@Test
fun activeTaskDetails_DisplayedInUi() = runBlockingTest{
// GIVEN - Add active (incomplete) task to the DB
val activeTask = Task("Active Task", "AndroidX Rocks", false)
repository.saveTask(activeTask)
// WHEN - Details fragment launched to display task
val bundle = TaskDetailFragmentArgs(activeTask.id).toBundle()
launchFragmentInContainer<TaskDetailFragment>(bundle, R.style.AppTheme)
}
}
- 运行
activeTaskDetails_DisplayedInUi()
测试。
与之前一样,您应该会看到该片段,但这次,因为您正确设置了资源库,所以它现在显示任务信息。
10. 任务:使用 Espresso 编写您的第一个集成测试
在此步骤中,您将使用 Espresso UI 测试库来完成您的第一个集成测试。您已经构建了代码,以便您可以添加包含 UI 断言的测试。为此,您将使用 Espresso 测试库。
Espresso 可以帮助您
- 与视图交互,例如单击按钮、滑动条或向下滚动屏幕。
- 断言某些视图是否在屏幕上或处于特定状态(例如包含特定文本,或者复选框是否已选中等)。
步骤 1. 注意 Gradle 依赖项
您已经拥有主要的 Espresso 依赖项,因为它默认包含在 Android 项目中。
app/build.gradle
dependencies {
// ALREADY in your code
androidTestImplementation "androidx.test.espresso:espresso-core:$espressoVersion"
// Other dependencies
}
androidx.test.espresso:espresso-core
—当您创建一个新的 Android 项目时,此核心 Espresso 依赖项默认包含在内。它包含大多数视图及其操作的基本测试代码。
步骤 2. 关闭动画
Espresso 测试在真实设备上运行,因此本质上是仪器测试。出现的一个问题是动画:如果动画滞后,并且您试图测试视图是否在屏幕上,但它仍在动画中,Espresso 可能会意外地使测试失败。这会使 Espresso 测试变得不稳定。
对于 Espresso UI 测试,最好关闭动画(您的测试运行速度也会更快!)
- 在您的测试设备上,转到 **设置 > 开发者选项**。
- 禁用以下三个设置:**窗口动画缩放比例**、**过渡动画缩放比例**和**动画时长缩放比例**。
步骤 3. 查看 Espresso 测试
在编写 Espresso 测试之前,请查看一些 Espresso 代码。
onView(withId(R.id.task_detail_complete_checkbox)).perform(click()).check(matches(isChecked()))
此语句的作用是查找 ID 为 task_detail_complete_checkbox
的复选框视图,单击它,然后断言它已选中。
大多数 Espresso 语句由四个部分组成
onView
onView
是一个静态 Espresso 方法的示例,它启动一个 Espresso 语句。onView
是最常用的方法之一,但还有其他选项,例如 onData
。
withId(R.id.task_detail_title_text)
withId
是 ViewMatcher
的一个示例,它通过其 ID 获取视图。还有其他视图匹配器,您可以在 文档 中查找。
perform(click())
perform
方法接受一个 ViewAction
。ViewAction
是可以对视图执行的操作,例如,这里,它单击视图。
check(matches(isChecked()))
check
接受一个 ViewAssertion
。ViewAssertion
检查或断言视图的某些内容。您将使用最常见的 ViewAssertion
是 matches
断言。要完成断言,请使用另一个 ViewMatcher
,在本例中为 isChecked
。
请注意,您并不总是同时调用 perform
和 check
来创建一个 Espresso 语句。您可以编写只使用 check
进行断言的语句,或者只使用 perform
执行 ViewAction
。
- 打开
TaskDetailFragmentTest.kt
。 - 更新
activeTaskDetails_DisplayedInUi
测试。
TaskDetailFragmentTest.kt
@Test
fun activeTaskDetails_DisplayedInUi() = runBlockingTest{
// GIVEN - Add active (incomplete) task to the DB
val activeTask = Task("Active Task", "AndroidX Rocks", false)
repository.saveTask(activeTask)
// WHEN - Details fragment launched to display task
val bundle = TaskDetailFragmentArgs(activeTask.id).toBundle()
launchFragmentInContainer<TaskDetailFragment>(bundle, R.style.AppTheme)
// THEN - Task details are displayed on the screen
// make sure that the title/description are both shown and correct
onView(withId(R.id.task_detail_title_text)).check(matches(isDisplayed()))
onView(withId(R.id.task_detail_title_text)).check(matches(withText("Active Task")))
onView(withId(R.id.task_detail_description_text)).check(matches(isDisplayed()))
onView(withId(R.id.task_detail_description_text)).check(matches(withText("AndroidX Rocks")))
// and make sure the "active" checkbox is shown unchecked
onView(withId(R.id.task_detail_complete_checkbox)).check(matches(isDisplayed()))
onView(withId(R.id.task_detail_complete_checkbox)).check(matches(not(isChecked())))
}
如有需要,以下是导入语句
import androidx.test.espresso.Espresso.onView
import androidx.test.espresso.assertion.ViewAssertions.matches
import androidx.test.espresso.matcher.ViewMatchers.isChecked
import androidx.test.espresso.matcher.ViewMatchers.isDisplayed
import androidx.test.espresso.matcher.ViewMatchers.withId
import androidx.test.espresso.matcher.ViewMatchers.withText
import org.hamcrest.core.IsNot.not
// THEN
注释后的所有内容都使用 Espresso。检查测试结构以及withId
的用法,并检查有关详细信息页面外观的断言。- **运行**测试并确认其通过。
步骤 4. 可选,编写您自己的 Espresso 测试
现在自己编写一个测试。
- 创建一个名为
completedTaskDetails_DisplayedInUi
的新测试,并复制此骨架代码。
TaskDetailFragmentTest.kt
@Test
fun completedTaskDetails_DisplayedInUi() = runBlockingTest{
// GIVEN - Add completed task to the DB
// WHEN - Details fragment launched to display task
// THEN - Task details are displayed on the screen
// make sure that the title/description are both shown and correct
}
- 查看之前的测试,**完成**此测试。
- **运行**并确认测试通过。
完成的 completedTaskDetails_DisplayedInUi
应该如下所示。
TaskDetailFragmentTest.kt
@Test
fun completedTaskDetails_DisplayedInUi() = runBlockingTest{
// GIVEN - Add completed task to the DB
val completedTask = Task("Completed Task", "AndroidX Rocks", true)
repository.saveTask(completedTask)
// WHEN - Details fragment launched to display task
val bundle = TaskDetailFragmentArgs(completedTask.id).toBundle()
launchFragmentInContainer<TaskDetailFragment>(bundle, R.style.AppTheme)
// THEN - Task details are displayed on the screen
// make sure that the title/description are both shown and correct
onView(withId(R.id.task_detail_title_text)).check(matches(isDisplayed()))
onView(withId(R.id.task_detail_title_text)).check(matches(withText("Completed Task")))
onView(withId(R.id.task_detail_description_text)).check(matches(isDisplayed()))
onView(withId(R.id.task_detail_description_text)).check(matches(withText("AndroidX Rocks")))
// and make sure the "active" checkbox is shown unchecked
onView(withId(R.id.task_detail_complete_checkbox)).check(matches(isDisplayed()))
onView(withId(R.id.task_detail_complete_checkbox)).check(matches(isChecked()))
}
11. 任务:使用 Mockito 编写导航测试
在最后一步中,您将学习如何使用不同类型的测试替身(称为模拟)和测试库 Mockito 来测试 导航组件。
在此 codelab 中,您使用了称为伪造的测试替身。伪造只是许多类型的测试替身之一。您应该使用哪种测试替身来测试 导航组件?
考虑一下导航是如何发生的。想象一下,在 TasksFragment
中按下其中一项任务以导航到任务详细信息屏幕。
这是 TasksFragment
中的代码,当按下它时,它会导航到任务详细信息屏幕。
TasksFragment.kt
private fun openTaskDetails(taskId: String) {
val action = TasksFragmentDirections.actionTasksFragmentToTaskDetailFragment(taskId)
findNavController().navigate(action)
}
导航是由于调用 navigate
方法而发生的。如果您需要编写一个断言语句,那么没有直接的方法来测试您是否已导航到 TaskDetailFragment
。导航是一个复杂的操作,除了初始化 TaskDetailFragment
之外,不会产生清晰的输出或状态变化。
您可以断言的是,使用正确的操作参数调用了 navigate
方法。这正是 **模拟** 测试替身的作用——它检查是否调用了特定方法。
Mockito 是一个用于创建测试替身的框架。虽然 API 和名称中使用了“mock”(模拟)一词,但它并非仅用于创建模拟对象。它还可以创建桩(stub)和间谍(spy)。
您将使用 Mockito 创建一个模拟的 NavigationController
,它可以断言 navigate 方法是否被正确调用。
步骤 1. 添加 Gradle 依赖项
- 添加 Gradle 依赖项。
app/build.gradle
// Dependencies for Android instrumented unit tests
androidTestImplementation "org.mockito:mockito-core:$mockitoVersion"
androidTestImplementation "com.linkedin.dexmaker:dexmaker-mockito:$dexMakerVersion"
androidTestImplementation "androidx.test.espresso:espresso-contrib:$espressoVersion"
org.mockito:mockito-core
—这是 Mockito 的依赖项。dexmaker-mockito
—在 Android 项目中使用 Mockito 需要此库。Mockito 需要在运行时生成类。在 Android 上,这是使用 dex 字节码完成的,因此此库使 Mockito 能够在 Android 上运行时生成对象。androidx.test.espresso:espresso-contrib
—此库包含外部贡献(因此得名),其中包含针对更高级视图(例如DatePicker
和RecyclerView
)的测试代码。它还包含辅助功能检查和稍后将介绍的CountingIdlingResource
类。
步骤 2. 创建 TasksFragmentTest
- 打开
TasksFragment
。 - 右键单击
TasksFragment
类名,然后选择生成,然后选择测试。在 **androidTest** 源集创建一个测试。 - 将此代码复制到
TasksFragmentTest
。
TasksFragmentTest.kt
@RunWith(AndroidJUnit4::class)
@MediumTest
@ExperimentalCoroutinesApi
class TasksFragmentTest {
private lateinit var repository: TasksRepository
@Before
fun initRepository() {
repository = FakeAndroidTestRepository()
ServiceLocator.tasksRepository = repository
}
@After
fun cleanupDb() = runBlockingTest {
ServiceLocator.resetRepository()
}
}
这段代码与您编写的 TaskDetailFragmentTest
代码类似。它设置并拆除了 FakeAndroidTestRepository
。添加导航测试以测试当您单击任务列表中的任务时,它是否会将您带到正确的 TaskDetailFragment
。
- 添加测试
clickTask_navigateToDetailFragmentOne
。
TasksFragmentTest.kt
@Test
fun clickTask_navigateToDetailFragmentOne() = runBlockingTest {
repository.saveTask(Task("TITLE1", "DESCRIPTION1", false, "id1"))
repository.saveTask(Task("TITLE2", "DESCRIPTION2", true, "id2"))
// GIVEN - On the home screen
val scenario = launchFragmentInContainer<TasksFragment>(Bundle(), R.style.AppTheme)
}
- 使用 Mockito 的
mock
函数创建一个模拟对象。
TasksFragmentTest.kt
val navController = mock(NavController::class.java)
要在 Mockito 中进行模拟,请传入您要模拟的类。
接下来,您需要将 NavController
与片段关联。onFragment
允许您调用片段本身的方法。
- 将新的模拟对象设为片段的
NavController
。
scenario.onFragment {
Navigation.setViewNavController(it.view!!, navController)
}
- 添加代码以单击文本为“TITLE1”的
RecyclerView
中的项目。
// WHEN - Click on the first list item
onView(withId(R.id.tasks_list))
.perform(RecyclerViewActions.actionOnItem<RecyclerView.ViewHolder>(
hasDescendant(withText("TITLE1")), click()))
RecyclerViewActions
是 espresso-contrib
库的一部分,它允许您对 RecyclerView 执行 Espresso 操作。
- 验证
navigate
是否已调用,并带有正确的参数。
// THEN - Verify that we navigate to the first detail screen
verify(navController).navigate(
TasksFragmentDirections.actionTasksFragmentToTaskDetailFragment( "id1")
Mockito 的 verify
方法是使它成为模拟对象的原因——您可以确认模拟的 navController
调用了具有参数的特定方法(navigate
)(actionTasksFragmentToTaskDetailFragment
以及 ID “id1”)。
完整的测试如下所示
@Test
fun clickTask_navigateToDetailFragmentOne() = runBlockingTest {
repository.saveTask(Task("TITLE1", "DESCRIPTION1", false, "id1"))
repository.saveTask(Task("TITLE2", "DESCRIPTION2", true, "id2"))
// GIVEN - On the home screen
val scenario = launchFragmentInContainer<TasksFragment>(Bundle(), R.style.AppTheme)
val navController = mock(NavController::class.java)
scenario.onFragment {
Navigation.setViewNavController(it.view!!, navController)
}
// WHEN - Click on the first list item
onView(withId(R.id.tasks_list))
.perform(RecyclerViewActions.actionOnItem<RecyclerView.ViewHolder>(
hasDescendant(withText("TITLE1")), click()))
// THEN - Verify that we navigate to the first detail screen
verify(navController).navigate(
TasksFragmentDirections.actionTasksFragmentToTaskDetailFragment( "id1")
)
}
- 运行您的测试!
总而言之,要测试导航,您可以:
- 使用 Mockito 创建
NavController
模拟对象。 - 将该模拟的
NavController
附加到片段。 - 验证是否已使用正确的操作和参数调用了 navigate。
步骤 3. 可选,编写 clickAddTaskButton_navigateToAddEditFragment
要查看您是否可以自己编写导航测试,请尝试此任务。
- 编写测试
clickAddTaskButton_navigateToAddEditFragment
,该测试检查如果单击 + FAB,您是否会导航到AddEditTaskFragment
。
答案如下。
TasksFragmentTest.kt
@Test
fun clickAddTaskButton_navigateToAddEditFragment() {
// GIVEN - On the home screen
val scenario = launchFragmentInContainer<TasksFragment>(Bundle(), R.style.AppTheme)
val navController = mock(NavController::class.java)
scenario.onFragment {
Navigation.setViewNavController(it.view!!, navController)
}
// WHEN - Click on the "+" button
onView(withId(R.id.add_task_fab)).perform(click())
// THEN - Verify that we navigate to the add screen
verify(navController).navigate(
TasksFragmentDirections.actionTasksFragmentToAddEditTaskFragment(
null, getApplicationContext<Context>().getString(R.string.add_task)
)
)
}
12. 解决方案代码
单击 此处 可查看您开始使用的代码与最终代码之间的差异。
要下载完成的 codelab 代码,可以使用下面的 git 命令
$ git clone https://github.com/google-developer-training/advanced-android-testing.git $ cd android-testing $ git checkout end_codelab_2
或者,您可以将存储库下载为 Zip 文件,解压缩它,然后在 Android Studio 中打开它。
13. 总结
本 codelab 涵盖了如何在 Android Kotlin 应用中设置手动依赖项注入、服务定位器以及如何使用伪造对象和模拟对象。特别是:
- 您想要测试的内容和您的测试策略决定了您将为应用实现哪种类型的测试。**单元测试**专注且快速。**集成测试**验证程序各个部分之间的交互。**端到端测试**验证功能,具有最高的保真度,通常是工具化的,并且可能需要更长的运行时间。
- 应用的架构会影响测试的难度。
- 为了隔离应用的各个部分以进行测试,您可以使用测试替身。**测试替身**是专门为测试而创建的类的版本。例如,您可以伪造从数据库或互联网获取数据。
- 使用**依赖项注入**将真实的类替换为测试类,例如存储库或网络层。
- 使用**工具化测试**(
androidTest
)启动 UI 组件。 - 当您无法使用构造函数依赖项注入时(例如启动片段),您通常可以使用服务定位器。**服务定位器模式**是依赖项注入的替代方案。它涉及创建名为“服务定位器”的单例类,其目的是为常规代码和测试代码提供依赖项。
14. 了解更多
示例
- 官方测试示例 - 这是官方测试示例,它基于此处使用的相同的 TO-DO Notes 应用。此示例中的概念超出了三个测试 codelab 中介绍的内容。
- 向日葵演示 - 这是主要的 Android Jetpack 示例,它也使用了 Android 测试库
- Espresso 测试示例
Udacity 课程
Android 开发人员文档
- 应用架构指南
runBlocking
和runBlockingTest
FragmentScenario
- Espresso
- Mockito
- JUnit4
- AndroidX 测试库
- AndroidX 架构组件核心测试库
- 源集
- 从命令行测试
- Android 上的依赖项注入
视频
- 关于 Android 依赖项注入的独到见解(Android Dev Summit ‘19)
- 构建可测试的 Android 应用(Google I/O ‘19)
- 片段:过去、现在和未来(Android Dev Summit ‘19) - 测试和片段部分
其他
15. 下一个 codelab
开始下一课:5.3:测试主题概述