在Android项目中将可复用能力抽离成Library模块，是组件化与代码复用的标准做法。但Library不同于可直接运行的App，它没有入口Activity，资源与Manifest常常需要消费方补全，这给测试带来了独特的挑战。我们需要一套既能验证内部逻辑、又不依赖宿主工程的测试方案。
Library模块测试的特殊性与目录规划
Android Library在被编译后会以AAR形式输出，它本身不参与最终APK的单一进程启动，因此在测试时应严格区分纯逻辑验证与依赖系统的验证。Gradle为Library提供了test与androidTest两个源集，前者运行在本地JVM，后者需要连接设备或者模拟器执行Instrumentation。很多团队误把全部用例写进androidTest，导致每次改动都要打包、安装、运行，反馈周期被拉到分钟级甚至更长。
合理的做法是：凡是只涉及算法、数据转换、状态机管理的类，全部放进test目录，使用JUnit加Mockito快速验证；只有必须用到真实Context、Resources或者自定义View绘制时，才下沉到androidTest。此外，Library的build.gradle中应显式关闭不必要的testInstrumentationRunner变体，避免测试代码渗入发布产物。下面是一段典型的Library模块测试依赖配置：
dependencies {
// 本地单元测试
testImplementation 'junit:junit:4.13.2'
testImplementation 'org.mockito:mockito-core:4.11.0'
testImplementation 'org.robolectric:robolectric:4.10.3'
// 设备化测试
androidTestImplementation 'androidx.test.ext:junit:1.1.5'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
}
通过上述划分，我们可以在CI中先跑testDebugUnitTest任务，秒级获得逻辑层反馈；再视情况触发connectedCheck。这种分层直接压低了回归成本，也避免了测试代码对主工程构建图的污染。
使用Robolectric在JVM上模拟Android环境
当Library内部存在调用Context.getSharedPreferences或TextUtils等框架API的代码，纯JUnit无法运行。传统方案是上真机，但Robolectric通过shadow类在JVM里重写了Android核心类，使我们可以在不启动Activity的情况下拿到近似真实的系统行为。它特别适合Library中工具类、轻量管理类的验证。
举例来说，一个封装了夜间模式判定的Library工具类，需要读取Resources中的配置。用Robolectric只需在测试类标注@RunWith(RobolectricTestRunner.class)并指定SDK，即可直接调用相关方法。以下示例演示如何验证主题工具：
@RunWith(RobolectricTestRunner.class)
@Config(sdk = 30)
public class ThemeUtilsTest {
@Test
public void testIsNightMode() {
Context context = ApplicationProvider.getApplicationContext();
// 模拟资源返回值
ThemeUtils.init(context);
boolean result = ThemeUtils.isNightMode();
assertFalse(result);
}
}
Robolectric的优势在于速度，单测平均耗时在毫秒到百毫秒之间，且能无缝接入普通JUnit报告。其局限是部分硬件相关或最新系统UI行为支持滞后，因此仍要保留少量Instrumentation用例做兜底。对于Library维护者，推荐以Robolectric覆盖百分之八十以上的分支，真机测试只盯交互边界。
Library专属UI测试与Espresso轻量校验
若Library提供了自定义View或复杂布局容器，仅用JVM测试不足以发现测量、布局、事件分发的问题。此时应在Library的androidTest中编写Espresso脚本，但注意不要在Library里依赖宿主App的页面。可创建一个仅供测试的Activity，在Manifest中用<activity>声明并标记为不导出，专门用于承载待测View。
Espresso的onView(withId(...))能精准定位Library内部控件，并校验文本、背景或点击事件。比如一个日历选择Library，需要验证选中态变化，可用如下代码：
@RunWith(AndroidJUnit4.class)
public class CalendarViewTest {
@Rule
public ActivityScenarioRule<TestActivity> rule =
new ActivityScenarioRule<>(TestActivity.class);
@Test
public void testSelectDate() {
onView(withId(R.id.calendar_view))
.check(matches(isDisplayed()));
onView(withText("15"))
.perform(click());
onView(withId(R.id.selected_text))
.check(matches(withText("2023-xx-15")));
}
}
这种轻量UI测试跑在 Library 自己的测试工程内，不会干扰使用方业务。配合Gradle的productFlavors还能针对不同的compileSdk做兼容验证。总结来看，Library测试的核心就是边界清晰、分层执行、用对工具，这样即使被多个App引用，也能持续保证底层组件的质量稳定。
Android_Library单元测试UI测试修改时间：2026-08-17 01:12:15