Android设备上Instrumented Tests误删应用数据的规避方法

嘿，我完全懂你这种数据丢失的崩溃感——辛辛苦苦攒的测试数据说没就没太闹心了！咱们来一步步拆解问题，从根源上解决这个破坏性测试的问题。

核心问题根源 #

首先得搞清楚为什么会出现这种情况：

• Android的connectedAndroidTest任务默认会在测试执行前清除目标应用的所有数据，不管你用的是真机还是模拟器。这是Android测试框架的默认行为，目的是保证测试环境的干净，但显然在你这种场景下帮了倒忙。
• 你提到模拟器上有应用目录和-test目录，但真机上只有一个，这说明你的测试进程没有和主应用进程完全隔离。正常来说，Instrumented Tests会运行在独立的-test进程里，不会触碰主应用的数据，但如果配置有问题，测试进程可能直接复用了主应用的进程空间，导致数据被清除。
• 哪怕测试用的是内存数据库，只要测试框架触发了clearPackageData操作，主应用的SharedPreferences、文件等数据都会被一并清除，和数据库存储位置无关。

具体解决方案 #

1. 禁用测试前的自动数据清除 #

这是最直接的解决办法，修改你的Module级build.gradle（或build.gradle.kts）配置，告诉测试框架不要清除应用数据：

android {
    defaultConfig {
        // 其他配置...
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        // 添加这行，禁用测试前清除数据
        testInstrumentationRunnerArguments clearPackageData: 'false'
    }
}

如果是KTS语法：

android {
    defaultConfig {
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testInstrumentationRunnerArguments["clearPackageData"] = "false"
    }
}

你也可以在AndroidManifest.xml的<instrumentation>标签里直接设置：

<instrumentation
    android:name="androidx.test.runner.AndroidJUnitRunner"
    android:targetPackage="com.your.app.package"
    android:clearPackageData="false" />

2. 确保测试进程与主应用完全隔离 #

要让真机也像模拟器一样生成-test目录，需要保证测试使用独立的应用ID。在build.gradle里添加测试应用ID的配置：

android {
    defaultConfig {
        // 主应用ID
        applicationId "com.your.app.package"
        // 测试应用ID，自动在主ID后加.test
        testApplicationId "${applicationId}.test"
    }
}

这样测试会安装一个独立的应用实例，和主应用的数据完全分开，哪怕测试清除数据，也不会影响你正在使用的主应用。

3. 精准控制测试任务，避免全量执行 #

不要直接跑./gradlew test connectedAndroidTest这种全量任务，而是指定具体的测试类或测试方法，减少误操作的概率：

# 只运行指定测试类
./gradlew connectedDebugAndroidTest --tests "com.your.app.package.YourTestClass"
# 只运行指定测试方法
./gradlew connectedDebugAndroidTest --tests "com.your.app.package.YourTestClass.yourTestMethod"

你还可以用JUnit的@Tag注解给测试分组，只运行特定组的测试：

@Tag("non-destructive")
@Test
public void nonDestructiveTest() {
    // 测试逻辑
}

然后在Gradle里配置只运行带该标签的测试：

android {
    testOptions {
        unitTests.all {
            useJUnitPlatform()
            includeTags 'non-destructive'
        }
        androidTests.all {
            useJUnitPlatform()
            includeTags 'non-destructive'
        }
    }
}

4. 验证内存数据库的配置 #

虽然你说用了内存数据库，但还是要确认测试代码里的初始化逻辑没有出错。比如用Room的话，一定要用inMemoryDatabaseBuilder，而不是普通的databaseBuilder：

// 正确的内存数据库初始化
Room.inMemoryDatabaseBuilder(context, AppDatabase.class)
    .allowMainThreadQueries()
    .build();

// 错误的本地数据库初始化（会写入文件）
Room.databaseBuilder(context, AppDatabase.class, "app.db")
    .allowMainThreadQueries()
    .build();

确保测试代码里没有不小心用了本地数据库的初始化逻辑。

额外防护措施 #

• 测试前自动备份数据：写一个简单的Shell脚本，在跑测试前用adb备份应用数据，测试完再恢复：

# 备份数据
adb backup -f app_backup.ab com.your.app.package
# 运行测试
./gradlew connectedDebugAndroidTest
# 恢复数据
adb restore app_backup.ab

• 使用单独的构建变体：创建一个专门用于测试的构建变体，比如debugTest，设置不同的applicationId，这样测试用的应用和主应用完全分开，互不干扰。
• 启用系统自动备份：在AndroidManifest.xml里开启应用备份，这样即使数据丢失，也能从系统备份恢复：

<application
    android:allowBackup="true"
    android:fullBackupContent="@xml/backup_rules">
    <!-- 其他配置 -->
</application>

内容的提问来源于stack exchange，提问作者GrzegDev