Android CI流水线集成Mock测试资料 - 第1节

1.1 到底什么是持续集成、持续交付、持续部署？

这三个词你肯定听过，但很多人分不清。

我先用一句话给你理清：持续集成（CI）是「天天合代码、天天跑测试」；持续交付（CD）是「随时能发布」；持续部署（CD）是「自动发到用户手上」。

说白了，这是一个从左到右的流水线：
开发 → 合代码 → 自动构建 → 自动测试 → 准备发布 → 自动上线。

1.1.1 持续集成（CI）—— 合代码不再是噩梦

我曾经在一个老项目里，团队十几个人，每次合并代码都得挑个「吉日」……因为一合就冲突，一冲突就编译不过。编译过了，跑一次全量测试又要 40 分钟。那段时间合并一次代码，半个组都要加班。

后来我搭了 CI，每个人 push 代码，服务器自动拉取、编译、跑单元测试和 Lint。如果失败，即时通知——谁引入的 bug 谁负责修，不用把问题拖到第二天。嗯，从那以后，合并代码就像喝咖啡一样轻松。

CI 的核心动作：

• 自动拉取最新代码
• 执行 Gradle 构建（assembleDebug / assembleRelease）
• 运行单元测试（testDebugUnitTest）
• 运行 Mock 测试（用 MockK / Mockito 模拟依赖）
• 代码质量检查（Detekt / Ktlint / Lint）

1.1.2 持续交付（CD）—— 包随时可用

持续交付不等于自动上线。它只保证：任何一次 CI 通过的版本，都可以直接用于发布。

我们团队以前每周五下班前才打 Release 包，经常漏掉某个 hotfix。用了持续交付后，每次主分支 CI 通过，GitHub Actions 自动把 APK 传到 fir.im 或 AppCenter，测试同学随时能下载最新版本。再也不用低声下气跟开发说「帮我打一个包」了。

1.1.3 持续部署（CD 完整版）—— 全自动发版

这个在移动端用得相对少，因为发布到应用商店需要审核。但如果你做的是企业内部分发、或者灰度测试，完全可以用持续部署。举个例子：

• GitLab CI 构建通过 → 自动上传到 Play Console 内部测试轨道
• 测试通过后 → 自动提升到封闭测试轨道
• 最终一键批准发布

我见过一个团队，每天自动发布 3～4 个内部版本给 QA 测试，效率极高——当然，前提是你的自动化测试覆盖要够硬。

---

1.2 为什么 Android 项目一定要用 CI？

讲道理，手机 app 比后端服务更需要自动化流水线。原因我给你列三个：

1. 构建耗时：Android 项目依赖多，Gradle 构建一次动不动 3–5 分钟。要是每个人都本地 build，一天下来浪费几十分钟。CI 在后台跑，不影响你写代码。
2. 测试碎片化：不同的 Android 版本、屏幕尺寸、API level……你不可能每台设备都测。CI 可以挂在几十种模拟器上并行跑。
3. Mock 数据隔离：后端接口不稳定，或者还没开发完，前端需要 mock 数据。CI 里集成 mock 测试，能保证你的 UI 在模拟数据下不出错。

所以，Android 项目的 CI 不是「要不要」的问题，而是「怎么设计好」的问题。一个合格的流水线至少包含：

阶段	任务	为什么重要
代码拉取 & 合入	git merge / rebase + 子模块同步	避免冲突遗留在主分支
静态检查	Lint / Detekt / Ktlint	代码风格一致，早期发现 bug 模式
单元测试 + Mock	JUnit + MockK / Mockito	验证业务逻辑，不依赖真实网络/数据库
构建产物	assembleDebug / bundleRelease	生成可直接安装/上传的包
自动化 UI 测试	Espresso / Compose UI Test	页面交互正确性（可选但推荐）

---

1.3 一张图看懂 CI/CD 在 Android 项目中的位置

下面这张图，我把刚才讲的内容串起来了。你重点关注箭头方向——从开发到上线，每一步都会经过「Mock 测试」这个质量门禁。