教育后端前端【免费下载链接】oppiaA free, online learning platform to make quality education accessible for all.项目地址https://gitcode.com/gh_mirrors/op/oppia点击查看免费下载在 Oppia 的 CI 流程中每一次 Pull Request 并不会盲目跑完全部测试而是通过一套部分 CIPartial CI机制精确挑选出受代码变更影响的测试套件来运行。这套机制的核心数据源就是core/tests/test-modules-mappings/目录下的测试模块映射test-modules-mappings文件。本文将从该目录的职责与结构出发结合scripts/check_ci_test_suites_to_run.py、运行时收集器core/tests/test-dependencies/test-to-modules-matcher.ts以及验收测试运行器等源码完整还原这些.txt映射文件从生成、消费到校验的整条链路。读完本文你将理解 CI 何时提示你更新这些文件、为什么不能手改、以及本地运行测试时它们是如何被自动重建的。一、test-modules-mappings 目录职责与现状根据core/tests/test-modules-mappings/README.md的官方说明该目录存放每种测试类型的模块映射test-modules-mappings当前仓库中它只包含验收测试acceptance tests的映射。这些映射的用途是决定在 GitHub CI 中运行哪些测试——也就是说它们是文件变更 → 受影响测试套件这条关联链路的静态数据底座。core/tests/test-modules-mappings/ ├── README.md └── acceptance/ ├── blog-admin/ │ └── assign-roles-to-users-and-change-tag-properties.txt ├── blog-editor/ │ ├── create-and-delete-draft-blog-post.txt │ ├── create-and-publish-a-blog-post-with-required-details.txt │ └── try-to-publish-a-duplicate-blog-post-and-get-blocked.txt ├── curriculum-admin/ │ ├── create-edit-and-delete-classroom.txt │ └── create-publish-unpublish-and-delete-topic-and-skill.txt ├── exploration-editor/ │ ├── create-exploration-and-change-basic-settings.txt │ ├── load-complete-and-restart-exploration-preview.txt │ ├── manage-exploration-misconceptions.txt │ ├── modify-translations-through-modal.txt │ ├── publish-the-exploration-with-an-interaction.txt │ └── save-draft-publish-and-discard-the-changes.txt ├── logged-in-user/ ├── moderator/ ├── practice-question-admin/ ├── release-coordinator/ ├── super-admin/ ├── topic-manager/ ├── translation-admin/ └── voiceover-admin/每个子目录对应一类用户角色/功能域目录内每个.txt文件与一个验收测试套件一一对应。文件内容格式非常简单——每行一个 Angular 模块文件路径按字典序排列。以exploration-editor/create-exploration-and-change-basic-settings.txt为例其真实内容为core/templates/pages/creator-dashboard-page/creator-dashboard-page.module.ts core/templates/pages/exploration-editor-page/exploration-editor-page.module.ts这表示创建探索并修改基础设置这个验收测试在运行过程中会加载两个页面级 Angular 模块只要 PR 改动了这两个模块中的任何一个该测试套件就需要被重新运行。super-admin/use-misc-tab-features.txt则列出了 7 个模块覆盖 admin-page、blog-admin-page、blog-dashboard-page、creator-dashboard-page、exploration-editor-page、topic-editor-page、topics-and-skills-dashboard-page 等页面说明该套件会穿梭于多个管理后台页面。二、模块映射与测试套件配置的对应关系映射文件并非孤立存在它与 core/tests/ci-test-suite-configs/acceptance.json 中的测试套件定义严格对应。该配置文件中每个套件包含三个字段字段说明示例name套件唯一标识形如角色域/行为描述exploration-editor/load-complete-and-restart-exploration-previewmodule对应的验收测试 spec 文件路径core/tests/puppeteer-acceptance-tests/specs/exploration-editor/load-complete-and-restart-exploration-preview.spec.tsframework运行框架当前取值puppeteer或playwrightpuppeteer映射.txt文件的文件名去掉.txt扩展名必须与套件name完全一致二者才能建立关联。这一匹配逻辑由 scripts/check_ci_test_suites_to_run.py 中的get_test_suites_to_module_mapping_from_file实现test_suite get_test_suite_by_name_from_list( test_suites, file_path_without_extension ) if test_suite is not None: test_suites_to_modules_mapping[test_suite[name]] modules从源码可以推断如果某个.txt文件名在acceptance.json中找不到同名的套件该文件会被静默跳过、不参与映射计算当前仓库中确实存在少量此类命名不一致的历史文件。因此新增或重命名套件时务必同时保证两边的name同步。三、消费端源码剖析check_ci_test_suites_to_run.py 如何挑选测试scripts/check_ci_test_suites_to_run.py是映射文件的直接消费方。它通过常量指向映射目录第 125-127 行TEST_MODULES_MAPPING_DIRECTORY: Final os.path.join( core, tests, test-modules-mappings )3.1 递归读取映射get_test_suites_to_module_mapping_from_directory第 528-563 行使用os.walk递归遍历core/tests/test-modules-mappings/acceptance目录下的所有文件逐个调用get_test_suites_to_module_mapping_from_file最终产出一个{套件名: [模块路径...]}字典。3.2 判断受影响的测试套件get_test_suites_affected_by_root_file第 586-619 行负责核心判定对于某个被修改的 root file即 Angular 模块遍历所有测试套件的模块映射若该模块出现在某套件的映射列表中或该文件本身就是套件配置中的modulespec 文件则将该套件标记为受影响同时凡是没有出现在任何映射中的套件也会被无条件纳入兜底策略确保无映射数据的套件始终被运行。3.3 完整决策流程get_ci_test_suites_to_run与main第 648-749 行串起了整体流程通过git diff --name-status获取 PR 变更文件列表若变更中包含 Python 文件直接运行全部测试套件Python 影响面无法静态收敛借助 core/tests/root-files-config.json 判断变更触及RUN_ALL_TESTS_ROOT_FILES中的文件如src/main.ts→ 跑全部仅触及RUN_NO_TESTS_ROOT_FILES如core/tests/test-modules-mappings/README.md本身→ 一个测试都不用跑其余情况将变更文件映射到 root files 后与 acceptance 映射比对得出acceptancepuppeteer playwright 混合与acceptance_playwright仅 playwright 子集两个维度的待跑套件列表连同 lighthouse 分片一起以TEST_SUITES_TO_RUN变量输出给 GitHub Workflow。scripts/check_ci_test_suites_to_run_test.py的单元测试完整验证了这一链路它在临时目录中构造blog-admin/assign-roles.txt、blog-editor/publish.txt、exploration-player/view-exploration.txt等模拟映射并逐一断言改动splash-banner.component.html只触发 splash 相关套件改动 spec 文件本身触发对应套件改动package.json触发全部套件等行为。四、映射文件的生命周期运行时自动收集与生成README 明确指出这些文件不应手动混入你自己的 Angular modules如果 CI 要求更新要么在本地运行测试让它们自动生成要么把 CI 给出的模块列表复制粘贴到目标位置。为什么可以自动生成秘密藏在验收测试的运行时收集器里。4.1 测试运行前指定 golden 文件路径在 core/tests/puppeteer-acceptance-tests/utilities/common/puppeteer-utils.ts 的openBrowser()中测试框架会根据当前运行的套件名动态指定 golden 文件路径TestToModulesMatcher.setGoldenFilePath( core/tests/test-modules-mappings/acceptance/${specName}.txt );其中specName由 scripts/servers.py 的managed_acceptance_tests_server通过环境变量注入os.environ[SPEC_NAME] suite_name也就是说跑哪个套件就对应更新哪个.txt文件。4.2 运行时 URL → 模块匹配core/tests/test-dependencies/test-to-modules-matcher.ts 中的TestToModulesMatcher承担核心收集工作静态属性routeToModuleMapping通过route-to-module-mapping-generator.ts在测试进程启动时解析整个 Angular 路由树建立URL 路由 → 页面模块的映射registerPuppeteerBrowser(browser)监听浏览器targetcreated/targetchanged事件以及页面framenavigated事件把每次导航的真实 URL 交给registerUrlregisterUrl用 Angular Router 的DefaultUrlSerializer解析 URL 并匹配路由匹配成功即把对应模块记入collectedModules同时借助COMMON_MODULES_TO_EXCLUDE第 35-53 行过滤掉 splash、login、signup、admin、learner-dashboard 等几乎所有套件都会访问的公共模块——除非该 golden 文件命中白名单 glob如super-admin/*仍会收集 admin-page 模块。4.3 测试结束后的比对与写回compareCollectedModulesWithGoldenFile第 203-256 行在测试收尾时执行三类校验缺失模块运行时收集到、但 golden 文件中没有 → 报错多余模块golden 文件中有、但本次运行未收集到 → 报错排序校验golden 文件必须按字典序排列 → 否则报错。最关键的机制在第 225-229 行无论校验结果如何它都会先把本次收集到的模块排序后写回 golden 文件fs.mkdirSync(path.dirname(this.goldenFilePath), {recursive: true}); fs.writeFileSync( this.goldenFilePath, this.collectedModules.sort().join(\n) \n );这正是 README 所说本地运行测试会自动生成映射文件的源码级证据在本地开发环境测试结束后文件已被自动更新若 CI 环境出现差异错误信息会提示你把 GitHub Actions 上传的 artifact 内容复制粘贴到 golden 文件位置即可。这也解释了为何永远不需要手写模块列表——浏览器真实访问过的页面会精确记录在案。五、为什么不能随意手动修改CI 的双重校验README 的告诫并非多虑Oppia 对映射文件设有两道自动防线运行时比对如上一节所述每个验收测试结束时都会校验 golden 文件与运行时收集结果的一致性任何手改造成的偏差都会让对应测试在本地或 CI 中直接失败CI 决策依赖check_ci_test_suites_to_run.py会以这些文件为唯一依据计算待跑套件。若你擅自添加自己的模块哪怕只是格式错误、漏了换行、顺序不对要么导致该套件被错误地跳过测试覆盖漏洞要么让本应运行的测试被多跑/少跑进而影响 PR 的 CI 通过率与执行时长。正确的两种更新姿势README 已给出并可由源码验证本地运行测试自动生成执行python -m scripts.run_acceptance_tests --suite suite-name测试结束写入真实收集的模块列表粘贴 CI artifact当 CI 报出missing/extra modules差异时直接从 Actions 日志或上传的 artifact 中复制模块列表到对应的.txt文件。此外check_tests_are_captured_in_ci.py还会交叉校验acceptance.json中的套件集合与specs目录下的实际测试文件是否同步防止新写的测试没有被登记到 CI 配置中。六、本地运行验收测试完整命令与前提如果你需要让映射文件自动重建可以在仓库根目录运行scripts/run_acceptance_tests.py 的使用说明python -m scripts.run_acceptance_tests --suiteexploration-editor/create-exploration-and-change-basic-settings常用参数参数作用--suite必填指定要运行的套件名必须与acceptance.json中的name一致--skip_build跳过前端构建默认会先 build JS 文件--headless以无头模式运行浏览器--mobile以移动端视口iPhone 6 规格运行--prod_env以生产模式运行静态资源从 build 目录提供--update_snapshots更新 Playwright 截图基线对 puppeteer 套件无效脚本会依次启动 Redis、Firebase Auth Emulator、Cloud Datastore Emulator 与 dev appserver端口由common.GAE_PORT_FOR_ACCEPTANCE_TESTING指定再拉起 jestpuppeteer或 Playwright 测试进程并以SPEC_NAME环境变量把套件名传给测试端最终触发openBrowser()中的 golden 文件写回逻辑。七、配套机制一览把文件变更翻译成测试清单映射文件只是 Partial CI 拼图的一块理解它需要看清整个配套体系均位于 core/tests/test-dependencies/ 与 core/tests/文件作用core/tests/test-dependencies/root-files-mapping-generator.ts静态分析 TS 依赖生成root-files-mapping.json把每个源文件映射到所属 root modulecore/tests/test-dependencies/route-to-module-mapping-generator.ts解析 Angular 路由模块产出URL → 页面模块映射供运行时收集器使用core/tests/test-dependencies/test-to-modules-matcher.ts运行时 URL 匹配、模块收集、golden 文件比对与写回core/tests/ci-test-suite-configs/acceptance.json验收测试套件的权威登记表name/module/frameworkcore/tests/root-files-config.jsonRUN_NO_TESTS_ROOT_FILES与RUN_ALL_TESTS_ROOT_FILES白名单注意core/tests/test-modules-mappings/README.md本身被列为改动不触发任何测试的文件scripts/check_ci_test_suites_to_run.py汇总以上所有输入输出TEST_SUITES_TO_RUN给 GitHub Workflow整条链路可概括为PR 变更文件 →root-files-mapping→ root modules →test-modules-mappings 反向查表→ 受影响套件 → 输出 CI 执行清单。而test-modules-mappings正是这张反向查表里唯一需要测试自己维护的数据——它由运行时收集器自动维护由 CI 消费也由 CI 校验形成了一条自洽、免手写的闭环。八、结语给贡献者的操作速查新增验收测试套件在acceptance.json登记套件含framework字段在specs目录编写测试本地跑一遍该套件后提交自动生成的.txt映射文件CI 提示更新映射优先本地运行对应套件让文件自动重建若本地环境不便则将 CI 日志/artifact 中给出的模块列表按字典序写入对应.txt切勿手动臆造模块重命名套件同步修改acceptance.json中的name、spec 文件路径以及映射.txt的文件名三者必须对齐只想了解结构直接阅读 core/tests/test-modules-mappings/README.md 与 core/tests/test-dependencies/README.md再对照本文提到的源码入口逐一验证即可。赞分享教育后端前端【免费下载链接】oppiaA free, online learning platform to make quality education accessible for all.项目地址https://gitcode.com/gh_mirrors/op/oppia点击查看免费下载相关推荐用 repowise impacted-tests 精准锁定变更影响的测试从每测试覆盖率映射到 CI 测试门禁用 repowise impacted tests 精准锁定变更影响的测试从每测试覆盖率映射到 CI 测试门禁 本篇技术指南围绕 Claude Code 插件Oppia CI 测试套件配置指南解读 core/tests/ci-test-suite-configs 的注册机制与运行链路Oppia CI 测试套件配置指南解读 core/tests/ci test suite configs 的注册机制与运行链路 导读 core/tests教育后端前端Wazuh API 集成测试映射脚本实战用 JSON 映射驱动 PR 级精准测试Wazuh API 集成测试映射脚本实战用 JSON 映射驱动 PR 级精准测试 本篇技术指南以 Wazuh 开源仓库中的 API 集成测试映射脚本 map网络安全IDS日志分析应用安全漏洞扫描创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考