在Android项目体量逐渐膨胀之后，测试常常变成负担而不是保障。很多团队写了不少测试用例，却因为环境搭建麻烦、运行慢、不稳定而放弃维护。本文从工程实践角度梳理几类可以直接落地的Tips，帮助你在不变更现有架构的前提下，把单元测试、UI自动化和运行时检测融入日常开发。
用Robolectric在JVM上完成Android组件单元测试
传统Android单元测试最大的痛点是依赖<Context>、<Application>等系统对象，导致必须运行在真机或模拟器。Robolectric通过Shadow机制在JVM层模拟了Android SDK的大部分实现，使得<Activity>、<SharedPreferences>等都可以直接实例化。这样一条测试用例从编译到执行往往只需几百毫秒，相比Instrumentation测试动辄几十秒的部署时间，效率提升非常明显。
接入方式并不复杂，在模块的build.gradle中增加依赖即可。测试类上通过@RunWith(RobolectricTestRunner.class)声明运行器，就能在测试方法里直接调用RuntimeEnvironment.getApplication()获取应用上下文。下面示例演示如何测试一个读取配置的工具类：
@RunWith(RobolectricTestRunner.class)
@Config(sdk = 30)
public class ConfigUtilTest {
@Test
public void testSaveAndRead() {
Context ctx = RuntimeEnvironment.getApplication();
ConfigUtil.saveUserId(ctx, "1001");
String id = ConfigUtil.getUserId(ctx);
assertEquals("1001", id);
}
}
这种写法的优势在于把Android环境变成可控的测试桩，不会因为系统版本差异导致随机失败。缺点是Shadow并非完整实现，涉及复杂UI渲染或硬件调用的代码仍建议用真机方案补充。团队可以把所有纯逻辑和轻量组件测试都迁移到Robolectric，CI上只跑这一层就能覆盖六成以上代码。
用Espresso编写稳定的UI交互测试
界面层回归往往靠人工点检，既慢又容易漏。Espresso提供了一套基于IdlingResource的同步机制，能够自动等待界面空闲再执行断言，从而避免手写sleep带来的不稳定。核心思路是通过onView(withId(R.id.btn_login))定位目标控件，再调用perform(click())触发动作，最后用check(matches(isDisplayed()))验证结果。
为了让用例可维护，建议把控件ID和操作步骤封装到Page Object中，不要直接在测试类里散写选择器。这样当布局文件调整时，只需改一处映射。下面代码展示了一个登录成功的典型流程：
@Test
public void loginSuccess() {
onView(withId(R.id.et_username)).perform(typeText("admin"), closeSoftKeyboard());
onView(withId(R.id.et_password)).perform(typeText("123456"), closeSoftKeyboard());
onView(withId(R.id.btn_login)).perform(click());
onView(withId(R.id.tv_welcome)).check(matches(withText("欢迎 admin")));
}
需要注意的是，Espresso默认在主线程执行，若业务里有异步请求，要借助IdlingRegistry注册自定义资源，否则断言会在网络返回前触发而误报。相对于UI Automator，Espresso只支持同一应用内，但速度快、语法简洁，适合做核心页面的冒烟测试。把它挂在每日构建任务里，可以有效拦住布局错乱和事件丢失类问题。
借助StrictMode提前暴露主线程违规
很多卡顿和ANR并不是逻辑错误，而是开发者无意间在主线程做了磁盘读写或网络请求。Android自带的StrictMode可以在开发阶段开启严苛策略，一旦违例就抛异常或打印红字日志。它不需要引入第三方库，在<Application>的onCreate中配置即可，是成本极低的自我保护机制。
典型配置是同时启用线程策略和虚拟机策略，前者监控磁盘与网络，后者监控Activity泄漏和未关闭的SQLite游标。示例如下：
public void onCreate() {
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork()
.penaltyLog()
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectActivityLeaks()
.detectLeakedSqlLiteObjects()
.penaltyLog()
.build());
}
super.onCreate();
}
开启后，在日志中搜索StrictMode标签就能看到具体堆栈，定位到是哪一行代码在主线碰了IO。由于只在DEBUG包生效，不会影响线上性能。把它和单元测试结合起来，相当于在编码期、构建期、运行期都布下检测点，整体测试效率自然提高。长期实践下来，这类Tips比事后用Profiler抓卡顿要省力得多。