本页概述了测试 Android 应用的核心要点，包括核心最佳实践及其优势。
测试的好处
测试是应用开发流程中不可或缺的一环。通过持续对应用运行测试，您可以在公开发布应用之前验证其正确性、功能行为和易用性。
您可以手动测试应用。您可以使用不同的设备和模拟器、更改系统语言，并尝试生成每种用户错误或遍历每种用户流程。
不过，手动测试的扩展性较差，并且很容易忽略应用行为的回归问题。自动化测试是指使用工具为您执行测试，这种方式更快速、更可重复，并且通常会在开发流程的早期为您提供有关应用的更实用反馈。
Android 中的测试类型
移动应用非常复杂，必须能够在多种环境中正常运行。因此，测试有很多种类型。
主题
例如，测试类型因主题而异：
- 功能测试：我的应用是否能按预期运行？
- 性能测试：测试是否快速高效？
- 无障碍功能测试：应用是否能与无障碍服务正常协作？
- 兼容性测试：它是否能够在所有设备和 API 级别上正常运行？
范围
测试还因大小或隔离程度而异：
- 单元测试或小型测试仅验证应用的一小部分，例如方法或类。
- 端到端测试或大型测试可同时验证应用的较大部分，例如整个屏幕或用户体验流程。
- 中型测试介于两者之间，用于检查两个或更多单元之间的集成。
测试的分类方式有很多。不过，对应用开发者而言，最重要的区别在于运行测试的位置。
插桩测试与本地测试
您可以在 Android 设备或其他计算机上运行测试：
- 插桩测试，在实体设备或模拟 Android 设备上运行。该应用与可注入命令和读取状态的测试应用一起构建和安装。插桩测试通常是界面测试，会启动应用，然后与其互动。
- 本地测试在开发机器或服务器上执行，因此也称为“主机端测试”。它们通常小巧且运行速度快，可将被测对象与应用的其余部分隔离。
并非所有单元测试都是本地测试，也并非所有端到端测试都在设备上运行。例如：
- 大型本地测试：您可以使用本地运行的 Android 模拟器，例如 Robolectric。
- 小型插桩测试：您可以验证代码能否很好地支持框架功能（例如 SQLite 数据库）。您可以在多台设备上运行此测试，以检查与多个 SQLite 版本的集成情况。
示例
以下代码段演示了如何在插桩界面测试中与界面互动，点击某个元素并验证是否显示了另一个元素。
Espresso
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Compose UI
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
以下代码段显示了 ViewModel 的单元测试的一部分（本地、宿主端测试）：
// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)
// When data is loaded
viewModel.loadData()
// Then it should be exposing data
assertTrue(viewModel.data != null)
可测试的架构
采用可测试的应用架构后，代码会遵循一种结构，让您可以轻松单独测试其不同部分。可测试的架构还有其他优势，例如更好的可读性、可维护性、可伸缩性和可重用性。
不可测试的架构会产生以下结果：
- 更大、更慢、更不稳定的测试。无法进行单元测试的类可能需要通过更大的集成测试或界面测试进行覆盖。
- 测试不同场景的机会较少。测试规模越大，速度就越慢，因此测试应用的所有可能状态可能并不现实。
如需详细了解架构准则，请参阅应用架构指南。
分离的方法
如果您可以从函数、类或模块的其余内容中提取部分函数、类或模块，那么测试将更简单且更有效。这种做法称为解耦，是可测试架构最重要的概念。
常见的分离技术包括：
- 将应用拆分为层，例如呈现层、网域层和数据层。您还可以将应用拆分为多个模块，每个模块对应一个模块。
- 避免向具有大量依赖项的实体（例如 activity 和 fragment）添加逻辑。将这些类用作框架的入口点，并将界面和业务逻辑移至其他位置，例如移至可组合项、ViewModel 或域层。
- 避免在包含业务逻辑的类中使用直接的框架依赖项。例如，请勿在 ViewModel 中使用 Android 上下文。
- 使依赖项易于替换。例如，使用接口，而不是具体实现。即使您不使用 DI 框架，也请使用依赖项注入。
后续步骤
现在，您已经了解了为什么应该测试以及两种主要类型的测试，接下来可以阅读测试内容或了解测试策略。
或者，如果您想创建自己的第一个测试并通过实践学习，请查看测试 Codelab。