移动开发【免费下载链接】react-native-code-pushReact Native module for CodePush项目地址https://gitcode.com/gh_mirrors/re/react-native-code-push点击查看免费下载本文是 react-native-code-push 仓库 CONTRIBUTING.md 的技术化解读与实践手册聚焦两件事如何在本地手动验证你对插件的改动以及如何运行仓库自带的 Android/iOS 端到端E2E测试套件。读完本文你将掌握从环境准备、依赖安装、本地插件链接到借助ANDROID_EMU、IOS_EMU、CLEAN、CORE、NPM等环境变量精确控制测试行为的完整技能并理解底层测试框架 code-push-plugin-testing-framework 的运作原理。背景说明Visual Studio App Center 已于 2025 年 3 月 31 日退役CodePush 随之退役本仓库已进入归档状态见 README.md。本文所有命令、脚本与路径均以当前归档仓库的实际内容为准。环境准备Node.js 与 npm使用本项目进行开发与测试前置条件是安装node.js和npm。npm随node.js安装包一并分发无需单独安装。安装完成后进入仓库根目录安装项目的开发依赖npm install这一步会同时安装运行时依赖与开发依赖。从 package.json 可以看到运行时依赖包括code-push、glob、inquirer、plist、semver、xcode等开发依赖则包括mocha测试运行器、typescript、tslint、archiver、express、body-parser等其中code-push-plugin-testing-framework以file:./code-push-plugin-testing-framework的形式作为本地依赖被引入——这正是测试框架与插件本体在同一仓库内协同工作的方式。手动验证插件改动本地调试工作流如果你修改了插件源码希望在不发布到 npm 的前提下验证改动效果按以下四步走克隆本仓库并进入仓库根目录安装依赖npm install在目标 React Native 项目中安装本地插件进入你的 React Native 项目根目录用本地仓库路径替换npm install的包名npm install local_path_to_your_clone_of_this_repo例如如果你的克隆位于/home/user/react-native-code-push则执行npm install /home/user/react-native-code-push。这样 React Native 项目会直接引用本地源码改动后无需重新发布即可生效。按照 README.md 中的步骤完成插件配置包括 iOS / Android / Windows 的原生接入分别参考 iOS Setup、Android Setup、Windows Setup以及在根组件中使用codePush高阶组件包裹应用。构建并在模拟器或真机上运行确认应用能正常启动、同步更新从而验证你的改动。从源码结构看插件的自动链接与脚本钩子定义在 package.json 的rnpm字段中Android 侧会自动生成new CodePush(...)的 package instanceiOS 侧会链接libz并注册postlink/postunlink脚本对应 scripts/postlink/run.js 与 scripts/postunlink/run.js。这意味着本地安装后原生工程链接通常会由工具链自动完成你只需按文档补齐部署密钥等配置。测试环境准备在运行测试前先确认两件事已按上文完成插件依赖安装已全局安装react-nativenpm install -g react-native此外不同平台还有各自的额外要求Android确保sdk\tools、sdk\emulator和sdk\platform-tools已加入PATH否则测试框架无法启动模拟器、执行adb命令。iOS确保已安装 CocoaPods且.gem/bin已加入PATH。支持的操作系统与测试平台插件的端到端测试覆盖 Android 与 iOS但能跑哪些测试取决于你的开发机操作系统操作系统支持的测试OS XAndroid、iOSWindows仅 Android需要注意的是即使某些模拟器管理命令如adb、xcrun simctl在你当前的系统上不可用测试框架也会按平台顺序android、ios依次执行例如在 Windows 上运行npm run test时iOS 部分会因环境不支持而无法完成。日常开发中更常见的是按平台单独运行测试见下文命令一节。测试流程详解从构建应用到执行用例根据 CONTRIBUTING.md 与测试框架源码一次完整的测试运行按以下阶段推进构建测试应用测试框架使用 test/template 中的模板工程在临时目录创建测试应用测试包名固定为com.testcodepush应用名为TestCodePush见 testConfig.js并针对 Android / iOS 分别构建。模板中的CODE_PUSH_TEST_APP_NAME、CODE_PUSH_SERVER_URL、CODE_PUSH_INDEX_JS_PATH等占位符会在运行时被真实值替换占位符定义见 testUtil.js。检查模拟器是否在运行如果目标平台所需的模拟器/仿真器没有启动框架会尝试启动最新的那个模拟器Android 侧通过emulator -list-avds取 AVD 列表中的最后一个作为默认目标通过adb shell pm list packages探测模拟器是否就绪就绪检查最多轮询 50 次、每次间隔 5 秒见 platform.jsiOS 侧通过xcrun simctl list解析出最新的 iPhone 模拟器 UDID用xcrun simctl getenv booted SIMULATOR_UDID探测启动状态。若模拟器启动失败测试直接失败所有必需的模拟器都必须可用这是端到端测试的前提。运行目标单元测试测试用例通过 mocha 执行外层 describe 的超时时间设置为 100 分钟单个用例超时约 20 分钟见 test.js 与 testBuilder.js足以覆盖下载更新 → 安装 → 重启 → 校验这类慢流程。测试框架的场景机制仓库的 E2E 测试并非死板脚本而是以场景scenario为单位组织每个场景是一个独立的 JS 文件描述一段特定的 CodePush 行为流。场景文件位于 test/template/scenarios例如scenarioSync.js、scenarioDownloadUpdate.js、scenarioInstall.js、scenarioSyncMandatoryRestart.js、scenarioRestart2x.js等覆盖了同步、下载、安装、强制更新、二次重启等典型路径。模板应用 test/template/index.js 通过require(./CODE_PUSH_INDEX_JS_PATH)动态加载场景并在componentDidMount中调用testScenario.startTest(this)启动场景测试期间应用通过 XMLHttpRequest 把CHECK_UPDATE_AVAILABLE、DOWNLOAD_SUCCEEDED、UPDATE_INSTALLED、SYNC_STATUS等测试消息回传给本地测试服务器CODE_PUSH_SERVER_URL/reportTestMessage由 serverUtil.js 负责匹配预期结果。测试断言则由 testBuilder.js 提供近似 mocha 的describe/it接口并额外支持scenarioPath与isCoreTest标记——后者正是COREtrue只跑核心测试的实现基础。环境变量精确控制测试行为以下是 CONTRIBUTING.md 中规定的全部环境变量它们的取值逻辑都能在 testConfig.js 与 platform.js 中找到对应实现环境变量作用示例ANDROID_EMU指定要使用的 Android 模拟器名称不设置时自动选用最新 AVDANDROID_EMUyourEmulatorNameHere npm run test:androidIOS_EMU指定要使用的 iOS 模拟器可带 UDID不设置时自动选用最新 iPhone 模拟器IOS_EMUiPhone 8 (0567DFF8-329E-41A3-BD6D-E48E9DD5EF39) npm run test:iosCLEAN设为true时每次都先强制杀掉并重启所需模拟器否则仅在未运行时启动CLEANtrue npm run testCORE设为true时只运行核心单元测试子集COREtrue npm run test:androidNPM设为true时从 npm 拉取已发布的插件包来测试而不是测试本地版本NPMtrue npm run test:iosRUN_DIR/UPDATE_DIR覆盖测试运行目录与更新包目录默认位于系统临时目录下见 testConfig.jsRUN_DIR/tmp/my-run npm run test:fast:androidANDROID_SERVER/IOS_SERVER覆盖测试服务器地址Android 默认为http://10.0.2.2:3001iOS 默认为http://127.0.0.1:3000见 platform.js 与 platform.jsANDROID_SERVERhttp://192.168.1.10:3001 npm run test:android跳过构建:fast后缀如果只想跑测试、不想每次重复构建应用可以在命令中加入:fast。例如npm run test:ios变成npm run test:fast:iosnpm run test:android变成npm run test:fast:android。常用测试命令默认全平台全量测试在 Android 和 iOS 上运行全部单元测试npm run test仅 iOSnpm run test:ios仅 Androidnpm run test:android更多组合示例所有可能的测试配置都有对应的 npm 任务。平台按android, ios的顺序依次执行。以下是 CONTRIBUTING.md 给出的全部组合# 只在 Android 上运行核心单元测试 COREtrue npm run test:android # 在 iOS 上运行全部单元测试并从 npm 拉取插件而非本地版本 NPMtrue npm run test:ios # 在 Android 和 iOS 上运行全部单元测试但跳过构建 npm run test:fast # 在 iOS 上运行全部单元测试并强制重启模拟器 CLEANtrue npm run test:ios # 在 Android 上运行核心单元测试并从 npm 拉取插件 NPMtrue COREtrue npm run test:android以上环境变量可以任意组合...and so on!——例如CLEANtrue NPMtrue COREtrue npm run test:fast:android也是合法的写法。npm 脚本与 mocha 的关系从 package.json 可以看到这些命令在底层是如何组装起来的npm 脚本等价命令testnpm run build:tests npm run test:setup npm run test:fasttest:androidnpm run build:tests npm run test:setup:android npm run test:fast:androidtest:iosnpm run build:tests npm run test:setup:ios npm run test:fast:iostest:setupmocha --recursive bin/test --android --ios --setuptest:setup:androidmocha --recursive bin/test --android --setuptest:setup:iosmocha --recursive bin/test --ios --setuptest:fastmocha --recursive bin/test --android --iostest:fast:androidmocha --recursive bin/test --androidtest:fast:iosmocha --recursive bin/test --iosbuild:testsnpm run clean npm run tslint tsc其中值得注意的几点--setup标志对应 testConfig.js 中的SETUP_FLAG_NAMEtest:setup*命令会在正式跑测试前完成创建测试工程 创建更新工程 启动模拟器的准备工作见 test.js。这也解释了为什么npm run test会比npm run test:fast多一步 setup。--android/--ios标志测试框架通过 testUtil.js 扫描 mocha 命令行参数判断本次要跑哪些平台对应 platform.js 中 Android 的--android与 IOS 的--ios。测试前先做类型检查build:tests会先跑tslint再执行tsc编译test/**/*.ts因此测试代码的质量与类型安全在运行前就已被静态保障。bin/test是编译产物目录测试用例以 TypeScript 编写入口为 test/test.ts编译后由 mocha 以--recursive方式递归发现。调试与常见问题定位结合 README.md 的 Troubleshooting 章节与测试框架实现可以归纳几条实用的排查建议先看日志sync等核心方法自带详细诊断日志可用平台工具iOS 的 Xcode Console、Android 的adb logcat过滤[CodePush]前缀消息日志同样会输出在测试运行器的 stdout 中。确认部署密钥如果sync/checkForUpdate返回404多半是部署密钥配错或版本号不匹配可核对 Info.plistiOS或strings.xmlAndroid中的配置。Debug 模式下更新不生效Debug 模式下 React Native 总是从 packager 加载 JS bundleCodePush 下载的 bundle 不会生效因此验证更新必须使用非 Debug 构建。测试框架自身的日志运行测试时框架会打印当前配置如test run directory、updates directory、--only running core tests--、--restarting emulators--等见 test.js据此可快速确认环境变量是否按预期生效。网络超时框架执行子进程命令时默认设置了 10 分钟超时、500MB 缓冲区见 testUtil.js若模拟器启动或构建步骤卡住可优先检查ANDROID_EMU/IOS_EMU指定的设备是否存在。结语CONTRIBUTING.md 虽然篇幅不长却完整勾勒出了 react-native-code-push 插件开发的本地验证闭环先用npm install 本地路径把改动接入真实 React Native 工程做手工冒烟再借助内置的端到端测试框架通过组合ANDROID_EMU、IOS_EMU、CLEAN、CORE、NPM等环境变量在 Android / iOS 模拟器上自动验证同步、下载、安装、回滚等关键路径。理解了 testConfig.js、test.js、testBuilder.js 与 platform.js 这四份核心源码你就能把文档中的每一条命令都映射到具体的执行逻辑上遇到问题也能更快定位到测试框架的哪一环出了问题。赞分享移动开发【免费下载链接】react-native-code-pushReact Native module for CodePush项目地址https://gitcode.com/gh_mirrors/re/react-native-code-push点击查看免费下载相关推荐从零搭建react-native-vision-camera端到端测试框架覆盖iOS/Android全流程从零搭建react native vision camera端到端测试框架覆盖iOS/Android全流程 你还在手动测试相机功能吗 移动端相机应用测试长期移动开发音视频Snowpack 贡献者开发指南monorepo 构建、测试与本地调试全流程Snowpack 贡献者开发指南monorepo 构建、测试与本地调试全流程 Snowpack 是一个 ESM 驱动的现代前端构建工具以免打包unbun前端开发工具前端构建React Native Firebase 测试工程指南基于 Jet 与 Detox 的 iOS / Android 端到端测试环境搭建与运行React Native Firebase 测试工程指南基于 Jet 与 Detox 的 iOS / Android 端到端测试环境搭建与运行 导读 本文基于移动开发后端上一篇Witty-Service三大沙箱隔离技术Docker、Local Process、E2B全方位对比指南下一篇IB-Robot未来展望路线图解析与具身智能发展趋势创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考