测试【免费下载链接】EarlGrey:tea: iOS UI Automation Test Framework项目地址https://gitcode.com/gh_mirrors/ea/EarlGrey点击查看免费下载EarlGrey 是 Google 开源的 iOS UI 自动化测试框架本指南以仓库根目录的 CONTRIBUTING.md 为核心系统讲解外部开发者参与 EarlGrey 开发所需经历的完整流程从签署贡献者许可协议CLA、遵循代码评审规范、满足单元/功能测试门槛到正确提交 GitHub Issue 与维护文档。读者读完本文后将能按照官方规范准备可合并的 Pull Request理解仓库内置 CIScripts/travis.sh的检查机制并掌握新 API 通过 Demo/EarlGreyContribs 项目孵化后再进入主框架的协作路径。贡献前的准备工作签署 Google 个体贡献者许可协议CLA在 EarlGrey 仓库可以正式采用你的代码之前必须先签署 Google Individual Contributor License Agreement个体贡献者 CLA该协议可在线完成。签署 CLA 的必要性在于你对你的改动拥有版权即使改动成为 EarlGrey 代码库的一部分这一版权仍然归属你Google 需要获得你的许可才能使用和分发这些代码Google 还需要确认你不会在明知代码侵犯他人专利权的情况下提交改动。签署时机遵循先评审、后签署的节奏你无需在提交代码评审之前就签署 CLA但必须在代码被合入代码库之前完成签署。也就是说提交 Pull Request 后等成员批准了再补签即可。对于较大的贡献官方建议先通过 Issue 跟踪器与团队沟通想法让维护者提前介入并给予指导。提前协调能有效避免后期返工带来的挫败感。企业贡献者的不同协议需要注意公司或组织corporation做出的贡献适用与上述不同的协议Google Software Grant and Corporate Contributor License Agreement软件授权与企业贡献者许可协议这一点在 CONTRIBUTING.md 末尾的 The small print 小节中明确说明。企业贡献者在提交代码前应确认采用哪一份协议。代码评审Code Review流程EarlGrey 规定所有提交包括项目成员自己的提交都必须经过评审。仓库使用 GitHub Pull Request 作为评审载体。提交的代码需要遵守下面的规则清单。Dos应当遵循的规范保持 Pull Request 聚焦一个 PR 只处理一个 Issue 或一个功能点。如果一次改动修复了多个独立问题优先拆分为多个 commit每个 commit 对应一个 Issue。PR 必须关联 GitHub Issue除纯粹的拼写/格式修正trivial spelling/formatting fixes外每个 Pull Request 都必须先有一个对应的 Issue。没有对应 Issue 的 PR请先创建 Issue 并与社区讨论以确认该问题的影响程度。这样团队才能确定优先级把精力集中在最紧迫的问题上缺少变更背景上下文的 PR无法保证能获得及时的评审和合并。提交前先跑通测试在提交任何代码改动之前必须确保 Tests/UnitTests 和 Tests/FunctionalTests 两个测试工程能够构建且全部测试通过。如果认为测试失败是框架本身的 bug请到 Issue 跟踪器提交 Issue。等待 CI 验证PR 通过人工初步评审后Travis 会运行全部单元测试与功能测试团队还会触发一次内部测试以检查是否引入进一步的破坏。每个阶段都会在 PR 上设置相应的标签labels一旦有测试被破坏维护者会通知你。纯代码外改动可跳过 CI如果 PR 不涉及任何代码改动例如只改文档可以在 git commit message 中加入[[ci skip]]来跳过 Travis 持续集成检查避免给 CI 增加不必要的负担。实验性 PR 不会被合并任何被标记为 experiment 的 PR在标题中注明或打上experiment标签都不会被合并。它的作用是分享一个原型从而从核心团队获取更多反馈。新 API 先进 EarlGreyContribs 孵化如果提议给 EarlGrey 新增自定义 API且该 API 仍处于实验阶段请把它加入 Demo/EarlGreyContribs 工程进行验证。同理任何新增的示例代码也必须先在 EarlGreyContribs 工程中验证。从仓库的工程结构看EarlGreyContribs 包含EarlGreyContribsObjective-C与EarlGreyContribsSwiftSwift两套界面代码并配有 EarlGreyContribsTests 和 EarlGreyContribsSwiftTests 两个测试 target二者均纳入持续集成。其 README 明确说明如果你向其中一个 target 添加了 API请在另一个 target 中同样复制一份If you add an API to either one of the targets, please replicate it in the other as well.以保证 ObjC 与 Swift 两条路径都被验证。遵循 Google 代码风格代码约定请参照 Google Objective-C style guide 与 Google Swift style guide评论和 Issue 的格式请使用 GitHub 的 Markdown 格式规范。Donts应当避免的行为不要随意刷 LGTM / 1除非被明确要求否则不要添加 LGTM 或 1它们只会增加对话噪音。避免过度细碎的 PR对于可以很容易合并成一次的改动不要拆成多个小而碎的 Pull Request。不要提交描述含糊的 PR模糊的描述会拉长评审时间因为评审者需要先分析代码到底做了什么更详尽的描述能帮助评审者理解评审对象。不要提交大而空的重构拒绝提交大规模重构/功能变更 模糊或极简描述 没有关联 Issue的 Pull Request。CI 的落地实现travis.sh 背后的检查矩阵上面提到的 Travis 检查并非空谈仓库中的 Scripts/travis.sh 完整实现了这套 CI 逻辑。脚本以TYPE环境变量驱动可以推断出其覆盖以下矩阵TYPE 取值执行内容对应工程/SchemeUNIT单元测试Tests/UnitTests/UnitTests.xcodeproj 的EarlGreyUnitTestsschemeFUNCTIONAL功能测试ObjCTests/FunctionalTests/FunctionalTests.xcodeproj 的EarlGreyFunctionalTestsschemeFUNCTIONAL_SWIFT功能测试Swift同一工程的EarlGreyFunctionalSwiftTestsschemeCONTRIBContribs 测试ObjCDemo/EarlGreyContribs/EarlGreyContribs.xcodeproj 的EarlGreyContribsTestsCONTRIB_SWIFTContribs 测试Swift同一工程的EarlGreyContribsSwiftTestsEXAMPLE_PODSPod 示例集成Demo/EarlGreyExample 的EarlGreyExampleTestsCARTHAGECarthage 构建EarlGrey.xcodeproj 的EarlGreyschemeRelease clean buildPACKAGE打包发布执行 Scripts/package.shRUBYgem 插件测试进入 gem 目录执行bundle install与rake其中execute_xcodebuild函数有几个值得注意的实现细节Scripts/travis.sh测试命令在失败时最多重试 3 次当xcodebuild以退出码 65 退出测试未启动失败且日志中没有出现 Test Suite 关键字时才会重试——这是针对测试尚未真正启动场景的容错脚本注释中也自嘲这是脆弱的检查可能在未来 Xcode 版本中失效输出通过xcpretty -sc格式化并同时写入xcodebuild.log便于失败分析除了检查xcodebuild退出码还会用正则.*[1-9]\d* unexpected扫描日志因为当测试的setUp/tearDown失败时 Xcode 不会返回错误码只会把 unexpected failure 写进日志需要额外兜底检查。这意味着贡献者提交 PR 时改动会同时被跑在单元测试、功能测试ObjC/Swift、Contribs 孵化测试和示例工程集成测试等多条 CI 流水线上任何一条失败都会阻塞合并。本地开发与测试环境准备在本地复现 CI 环境、跑通单元测试与功能测试需要先准备 EarlGrey 的三方依赖。仓库提供了一键脚本 Scripts/setup-earlgrey.sh它会自动下载并安置三份依赖fishhook版本固定为 0.2facebook 的 C 函数钩子库用于 EarlGrey 运行时对系统调用的拦截下载后放在仓库根目录fishhook/OCHamcrest版本固定为 OCHamcrest-5.0.0iOS 的 Hamcrest 匹配器实现是 EarlGrey 匹配器体系的基础下载后需要执行 Scripts/rename-ochamcrestIOS.py 去掉 IOS 命名最终形成EarlGrey/OCHamcrest.frameworkOCMockmaster 分支Objective-C mock 框架供单元测试使用下载后放在 Tests/UnitTests/ocmock 目录。脚本设计为幂等如果对应目录已存在则跳过下载并给出提示若后续运行 EarlGrey 出现问题官方建议删除这些目录后重新运行脚本。对应地Demo/EarlGreyContribs/README.md 的 Getting Started 也推荐先运行 setup 脚本再打开已预配置好测试 target 的EarlGreyContribs.xcodeproj。GitHub Issues 规范Dos高质量 Issue 的标准先充分检索文档在提交 Issue 之前务必先广泛检索现有文档包括 docs 目录下的 api.md、features.md、faq.md 等作为开发者请提供你自己都愿意阅读的 Issue 描述。尽量详细在评论和描述中尽可能详细。每个 Issue 都要附上项目类型、使用的语言、Xcode 版本、错误堆栈error trace等。团队不希望为每个 Issue 都反复追问调试信息。深度讨论走邮件组深入的讨论请使用 EarlGrey Google Group而不是开一个新的 GitHub Issue。API 变更必须同步文档一旦发生 API 更新请确保改动被记录在 docs/cheatsheet/cheatsheet.html 中。而 cheatsheet 的 PDF 和 PNG 版本cheatsheet.pdf、cheatsheet.png只在发布新的 EarlGrey CocoaPod 时更新——从仓库 Scripts/package.sh 可以看到发布打包流程会把README.md、CHANGELOG.md、LICENSE和构建出的EarlGrey.framework一起打进 EarlGrey.zip作为 GitHub Release 与 CocoaPod 部署的产物这与PDF/PNG 随 CocoaPod 更新的约定是相互印证的。Donts会被直接关闭的 Issue含糊其辞的 Issue 会立即被关闭Any vaguely worded issue will be immediately closed长期无活动的 Issue 会被关闭如果某个 Issue 长时间没有动静它会被关闭若问题仍然存在请更新该 Issue 并重新打开。变更日志与版本配套约定虽然 CONTRIBUTING.md 没有逐字展开但从仓库配套文件可以推断出与贡献流程直接相关的配套约束CHANGELOG.md 记录了每个版本的变更采用语义化版本semantic versioning且每个版本条目会给出 Baseline commit 与 Enhancement/Bug Fixes/Compatibility 分类。贡献者提交用户可见的改动时合理的做法是同时在 CHANGELOG 中留下对应条目。版本配套的兼容性声明如 tested for working till Xcode version 10.1 and Swift 5都写在 CHANGELOG 的 Compatibility 小节中贡献者应避免引入超出声明范围的依赖。与贡献流程相关的框架内联约束最后从源码层面补充一个与提交前检查呼应的细节EarlGrey 在运行时有一系列可配置项EarlGrey/Common/GREYConfiguration.m其中kGREYConfigKeyAnalyticsEnabled默认值为YES——即默认启用匿名使用统计GREYAnalytics.m 在GREY_CONFIG_BOOL(kGREYConfigKeyAnalyticsEnabled)为真时才上报。这对贡献者意味着跑测试时产生的统计请求属于框架预期行为而在 Tests/FunctionalTests/Sources 中还有一组FTRAnalytics*Test.m专门验证分析开关、tearDown 后的退出opt-out行为。贡献者在编写或修改涉及配置默认值的代码时应保证这类行为测试仍然通过。小结一次完整的 EarlGrey 贡献旅程综合以上规范一个标准的贡献流程可以概括为沟通通过 Issue 跟踪器说明想法与社区确认影响范围与优先级准备本地运行 Scripts/setup-earlgrey.sh 装好 fishhook、OCHamcrest、OCMock 三份依赖开发遵循 Google ObjC/Swift 代码风格保持 PR 聚焦单一 Issue新 API 先放进 Demo/EarlGreyContribsObjC 与 Swift 双 target 都要覆盖孵化验证自测确保 Tests/UnitTests 与 Tests/FunctionalTests 构建通过、测试全绿涉及 API 变更时同步更新 docs/cheatsheet/cheatsheet.html提交创建关联 Issue 的 Pull Request接受 Travis 全矩阵检查单元/功能/Contribs/示例集成必要时用[[ci skip]]跳过纯文档改动的构建签署在代码合入前完成 Google 个体 CLA企业贡献者则走企业 CLA合并通过人工评审与 CI 后合入非代码改动会触发内部测试复检。这条流程既保证了 EarlGrey 这一被广泛依赖的测试框架的质量底线也让外部贡献者的工作有章可循、可预期。赞分享测试【免费下载链接】EarlGrey:tea: iOS UI Automation Test Framework项目地址https://gitcode.com/gh_mirrors/ea/EarlGrey点击查看免费下载相关推荐JanusGraph 贡献指南从签署 CLA 到合并 PR 的完整协作流程JanusGraph 贡献指南从签署 CLA 到合并 PR 的完整协作流程 本篇指南以 JanusGraph 官方仓库的 CONTRIBUTING.md ht图数据库分布式数据库后端BentoPDF 贡献指南从 CLA 签署到代码合入的完整协作流程BentoPDF 贡献指南从 CLA 签署到代码合入的完整协作流程 BentoPDFThe Privacy First PDF Toolkit是一个注重隐前端Chocolateychoco开源贡献指南从 CLA 签署到 Pull Request 合并的完整流程Chocolateychoco开源贡献指南从 CLA 签署到 Pull Request 合并的完整流程 Chocolatey 是 Windows 平台的包包管理器CLI开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考