testing-setup

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Step 1: analyze the current testing setup

步骤1：分析当前测试设置

To understand the testing setup of an existing project, look for these dependencies in the libs.versions.toml file, or build files:

Dependency Injection framework used. Examples: Hilt, Koin, Anvil, vanilla Dagger...
Unit (local) testing framework this project uses, Example JUnit4, JUnit5...
Mocking framework (if any) used for unit tests, and for Instrumented and UI tests. Examples: Mockito, Mockk...
Robolectric. It can be used in 3 ways:
1. Used in unit tests to have fakes for platform entities
2. To run behavior UI tests without a device or emulator. For example, used to run Espresso or Compose tests.
3. To do screenshot testing with Roborazzi
Is the app 100% Compose, Views or hybrid?
Behavior UI tests:
1. Compose Tests (
```
androidx.compose.ui:ui-test-*
```
  )
2. Espresso Tests for Views. Might use wrappers like Kaspresso. Dependencies:
```
androidx.test.espresso:espresso-core
```
  ,
```
androidx.test:runner
```
  ,
```
androidx.test:rules
```
  .
Screenshot tests can be:
1. Instrumented (device-based). For example, using Dropshots.
2. Based on Robolectric, so they run locally. For example, using Roborazzi.
3. Based on LayoutLib, so they run locally. For example, Paparazzi, or the Compose Preview Screenshot Testing tool.
End to end tests (also known as Release Candidate tests) always run on device and use high-level frameworks such as UIAutomator, Appium, or Robotium.
Generate a Markdown report with the analysis

要了解现有项目的测试设置，请在libs.versions.toml文件或构建文件中查找以下依赖项：

使用的依赖注入框架。示例：Hilt、Koin、Anvil、原生Dagger……
项目使用的单元（本地）测试框架，示例：JUnit4、JUnit5……
单元测试以及Instrumented测试和UI测试中使用的Mock框架（如有）。示例：Mockito、Mockk……
Robolectric的三种使用方式：
1. 在单元测试中用于为平台实体提供模拟实现
2. 在无需设备或模拟器的情况下运行行为UI测试。例如，用于运行Espresso或Compose测试。
3. 结合Roborazzi进行截图测试
应用是100%基于Compose、Views还是混合架构？
行为UI测试：
1. Compose Tests（
```
androidx.compose.ui:ui-test-*
```
  ）
2. 针对Views的Espresso Tests，可能会使用Kaspresso等封装库。依赖项：
```
androidx.test.espresso:espresso-core
```
  、
```
androidx.test:runner
```
  、
```
androidx.test:rules
```
  。
截图测试类型：
1. 基于设备的Instrumented测试。例如，使用Dropshots。
2. 基于Robolectric，可在本地运行。例如，使用Roborazzi。
3. 基于LayoutLib，可在本地运行。例如，Paparazzi或Compose Preview截图测试工具。
端到端测试（也称为Release Candidate测试）始终在设备上运行，使用UIAutomator、Appium或Robotium等高层框架。
生成包含分析结果的Markdown报告

Step 2: Set up Dependency Injection frameworks for testing

步骤2：为测试设置依赖注入框架

If there is no Dependency Injection framework, install one: if it's a multiplatform application, ask the user whether they want to install Koin, or kotlin-inject. If it's not multiplatform, install Hilt.

Install the testing dependencies (for example

com.google.dagger:hilt-compiler

that should be applied with a

kspAndroidTest

configuration).

[!IMPORTANT] Important: Always consult the documentation of the applicable framework to learn about testing (for example: Hilt testing guide, Koin Instrumented tests).

For instrumented tests, create and configure (by adding

testInstrumentationRunner

to the build gradle files) a new test runner and apply the testing rules required by the framework (for example in Hilt, annotate your test classes with

@HiltAndroidTest

and apply the

HiltAndroidRule

). Other frameworks use other mechanisms, consult their documentation.

如果没有依赖注入框架，请安装一个：如果是多平台应用，请询问用户是否要安装Koin或kotlin-inject；如果不是多平台应用，则安装Hilt。

安装测试依赖项（例如

com.google.dagger:hilt-compiler

，应通过

kspAndroidTest

配置应用）。

[!IMPORTANT] 重要提示： 务必查阅对应框架的文档了解测试相关内容（例如：Hilt测试指南、Koin Instrumented测试）。

对于Instrumented测试，创建并配置新的测试运行器（通过在build gradle文件中添加

testInstrumentationRunner

），并应用框架所需的测试规则（例如在Hilt中，用

@HiltAndroidTest

注解测试类并应用

HiltAndroidRule

）。其他框架使用不同机制，请查阅其文档。

Step 3: Install frameworks

步骤3：安装测试框架

Unless otherwise specified, respect the current stack of testing frameworks.

If there are no testing frameworks, and the user didn't specify any preference, install the following:

JUnit4 for local and instrumented tests
Jacoco for test coverage
For UI tests: if the project has views, Espresso. If it's fully Compose, use the Compose Testing APIs.
Robolectric to run UI Tests
Compose Preview Screenshot Testing tool for screenshot tests - check setup documentation and follow it strictly.
Dropshots for device screenshot tests
If a mocking framework is necessary, install Mockk (
```
io.mockk:mockk
```
). Do not install it unless it is clearly necessary.

If instrumented screenshot tests are requested, install Dropshots.

If end-to-end testing is requested, install UI Automator.

除非另有说明，否则遵循当前的测试框架栈。

如果没有测试框架且用户未指定偏好，请安装以下组件：

JUnit4用于本地和Instrumented测试
Jacoco用于测试覆盖率统计
UI测试：如果项目使用views，则安装Espresso；如果完全基于Compose，则使用Compose Testing APIs
Robolectric用于运行UI测试
Compose Preview截图测试工具用于截图测试——严格遵循设置文档
Dropshots用于设备端截图测试
如果需要Mock框架，则安装Mockk（
```
io.mockk:mockk
```
）。仅在明确需要时才安装。

如果需要Instrumented截图测试，请安装Dropshots。

如果需要端到端测试，请安装UI Automator。

Step 4: Refactor and create fakes for testing

步骤4：重构并创建测试用模拟实现（Fakes）

Refactor for unit tests

为单元测试重构

In the next sections you'll be asked to create tests. If you have dependencies on Android framework classes, or entities that are not part of the codebase:

First, use a fake. If it doesn't exist, create an interface for the class and a "Default" implementation with the existing code. Add the Fake version to the test sourceset (test or androidTest).
If not possible to use a fake (example: no access to the class or interface), mock the dependencies.

在后续步骤中创建测试时，如果依赖Android框架类或不属于代码库的实体：

首先使用模拟实现（Fake）。如果不存在，则为该类创建一个接口，并基于现有代码实现一个“默认”版本。将Fake版本添加到测试源码集（test或androidTest）。
如果无法使用Fake（例如：无法访问类或接口），则Mock相关依赖。

Refactor for UI tests

为UI测试重构

If you need to fake components to make testing easier and faster and more reliable, replace slow and problematic dependencies with fakes. Use runtime fakes using the Dependency Injection framework installed to:

Simulate different scenarios with the user (wrong credentials, reset password flow...), with a server (no connection, server down, bad JSON from server...) or with a platform component (insufficient permissions, no disk space, no front camera available)
Improve speed and reliability (replacing a database with an in-memory database, replacing a repository with an in-memory fake to avoid hitting the network)

如果需要通过模拟组件来让测试更简单、快速且可靠，请用Fake替换缓慢且易出问题的依赖。使用已安装的依赖注入框架实现运行时Fake，以：

模拟不同场景：用户场景（错误凭据、重置密码流程……）、服务器场景（无连接、服务器宕机、服务器返回错误JSON……）或平台组件场景（权限不足、磁盘空间不足、无前置摄像头……）
提升测试速度和可靠性（用内存数据库替换真实数据库，用内存Fake替换仓库以避免网络请求）

Step 5: Unit testing

步骤5：单元测试

Create a task to add or review unit tests in every file that contains business logic (ViewModels, Repositories, database-related classes such as DAOs, etc.). Don't create unit tests for Activities, Compose layouts, or dependency injection configuration files.

创建任务，为所有包含业务逻辑的文件（ViewModels、Repositories、数据库相关类如DAOs等）添加或审核单元测试。不要为Activities、Compose布局或依赖注入配置文件创建单元测试。

Step 6: UI testing

步骤6：UI测试

Espresso or Compose UI tests live in the

test

sourceset because they will be run with Robolectric. If instrumented (emulator or device) tests are requested, put them in the

androidTest

sourceset.

Espresso或Compose UI测试位于

test

源码集，因为它们将通过Robolectric运行。如果需要Instrumented（模拟器或设备）测试，请将其放在

androidTest

源码集。

Step 7: Test databases

步骤7：数据库测试

If the database is using SQLite (using Room, SQLDelight, etc.), create instrumented tests using an in-memory database to make sure that they work with the SQLite engine on device.

如果数据库使用SQLite（通过Room、SQLDelight等），请使用内存数据库创建Instrumented测试，确保其能在设备上的SQLite引擎正常工作。

Step 8: Screenshot tests

步骤8：截图测试

Irrespective of the framework used, screenshot tests focus on 2 types of tests:

Screen-level screenshot tests, where each screen is tested in 9 different sizes, combining compact, medium and expanded widths (400, 610, 900 dp) and heights (400, 500 and 1000 dp).
Screen-level variations. Add a mobile (400x500) screenshot of:
- All the alternative themes, if used.
- Font scale set to 1.5.
Component-level screenshot tests, where each component is tested in different themes and font scales.

Behavior isn't tested with screenshots, but do test different common scenarios if their UIs change a lot depending on the state. For example, test loading screens by injecting a loading state to the UI or simulating it with a fake.

无论使用哪种框架，截图测试都聚焦于两类测试：

屏幕级截图测试：每个屏幕需在9种不同尺寸下测试，组合紧凑、中等和扩展宽度（400、610、900 dp）以及高度（400、500和1000 dp）。
屏幕级变体测试：添加移动端（400x500）截图，包括：
- 所有使用的替代主题
- 字体缩放设置为1.5的情况
组件级截图测试：每个组件需在不同主题和字体缩放比例下测试。

截图测试不验证行为，但如果UI会根据状态发生较大变化，则需测试不同常见场景。例如，通过向UI注入加载状态或用Fake模拟来测试加载界面。

Step 9: UI Behavior tests

步骤9：UI行为测试

Test the UI logic using behavior tests, which ensures that the UIs react as expected when different states are passed, and when user actions are performed.

使用行为测试验证UI逻辑，确保在传入不同状态或执行用户操作时，UI能按预期响应。

Compose UI behavior tests

Compose UI行为测试

Use the ComposeTestRule with a
```
ComponentActivity
```
to access resources such as strings.
Always try to match with semantic matchers first. If the matcher is too complicated to write (using more than 3 matchers to find a single element), use
```
testTag
```
.
Always verify state restoration

使用ComposeTestRule搭配
```
ComponentActivity
```
以访问字符串等资源。
优先尝试使用语义匹配器。如果编写匹配器过于复杂（使用超过3个匹配器才能找到单个元素），则使用
```
testTag
```
。
务必验证状态恢复

Views (XML) UI behavior tests

Views（XML）UI行为测试

Use Espresso to match views and interact with them.

使用Espresso匹配视图并与之交互。

Step 10: Navigation tests

步骤10：导航测试

Create a test suite to verify navigation logic. Include:

Back handling
Deeplinks
Special patterns like "exit through home" with multiple backstacks.

创建测试套件验证导航逻辑，包括：

返回操作处理
深度链接
特殊模式，如带有多个返回栈的“通过主页退出”

Step 11: Simulate different window sizes and settings

步骤11：模拟不同窗口尺寸和设置

For Compose layouts, use

DeviceConfigurationOverride

described in "UI testing common patterns" to simulate different window sizes, font scales

对于Compose布局，使用“UI测试常见模式”中描述的

DeviceConfigurationOverride

来模拟不同窗口尺寸、字体缩放比例。

Step 12: End-to-end tests

步骤12：端到端测试

Create a low number (about 5% of all tests) of end-to-end tests that cover big user journeys. Use Compose Test APIs or Espresso for that. If you have to access platform features (notifications, system UI...), use UI Automator.

If you need to take screenshots of the app running in a device, use Dropshots. You need a device for screenshot tests when verifying interaction with the system UI (examples: edge-to-edge rendering, notifications, picture-in-picture)

创建少量（约占所有测试的5%）端到端测试，覆盖核心用户流程。使用Compose Test APIs或Espresso实现。如果需要访问平台功能（通知、系统UI……），则使用UI Automator。

如果需要对设备上运行的应用截图，请使用Dropshots。当验证与系统UI的交互时（例如：全屏渲染、通知、画中画），需要使用设备进行截图测试。

Step 13: Instrumented Screenshot tests

步骤13：Instrumented截图测试

Install the

com.dropbox.dropshots

plugin in the module and a

Dropshots()

JUnit Rule. Create a new instrumented screenshot test for one of the app's features.

在模块中安装

com.dropbox.dropshots

插件，并添加

Dropshots()

JUnit Rule。为应用的某一功能创建新的Instrumented截图测试。

Step 14: Install jacoco

步骤14：安装Jacoco

Install jacoco for local testing code coverage.

Add the
```
jacoco
```
plugin to each module that contains tests.

安装Jacoco用于本地测试代码覆盖率统计。

为每个包含测试的模块添加
```
jacoco
```
插件。

Final touches

最后收尾

Ask whether to document the findings of the analysis and the changes applied to the testing strategy. If the user agrees:
- If there is an AGENTS.md file present in the project, update it with any changes you've made to the testing strategy.
- If there is no AGENTS.md file, create a new file (docs/testing.md) with a description of the testing strategy, including the commands needed to run every type of test, where the screenshot reference files live, etc. Also create a new AGENTS.md file in the root and create a link to docs/testing.md.

询问是否要记录分析结果以及对测试策略所做的更改。如果用户同意：
- 如果项目中存在AGENTS.md文件，更新该文件，添加对测试策略所做的所有更改。
- 如果没有AGENTS.md文件，创建新文件（docs/testing.md），描述测试策略，包括运行各类测试所需的命令、截图参考文件的存储位置等。同时在根目录创建新的AGENTS.md文件，并添加指向docs/testing.md的链接。