后端前端开发工具【免费下载链接】compiler-explorerRun compilers interactively from your web browser and interact with the assembly项目地址https://gitcode.com/gh_mirrors/co/compiler-explorer点击查看免费下载Compiler Explorer 是一个在浏览器中交互式运行编译器并查看汇编输出的开源项目其前端界面高度依赖 GoldenLayout 面板、Monaco 编辑器与大量异步编译/API 请求对端到端测试提出了独特挑战。本文以仓库内 cypress/README.md 为核心骨架结合 cypress/support/utils.ts、cypress.config.ts 及cypress/e2e/下的真实测试用例系统讲解如何在 Compiler Explorer 中搭建 Cypress E2E 测试环境、规避 GoldenLayout 模板元素、管理 intercept 生命周期等关键问题读完即可上手编写稳定、可维护的前端 E2E 测试。一、测试环境准备启动干净的 Compiler Explorer 实例Compiler Explorer 的所有 Cypress 测试存放于cypress/e2e/目录都依赖一个本地运行的 CE 实例。启动命令如下npm run dev -- --language c --no-local其中--no-local标志至关重要它确保测试环境不会加载任何本地 properties 配置从而让每次测试都运行在一套干净、可复现的配置之上。这一点在 docs/UsingCypress.md 中有同样的强调。--language c指定默认语言为 C保证测试页初始代码与断言如默认代码输出中包含square符号一致。从package.json看dev脚本的实际定义为cross-env NODE_ENVDEV node --no-warningsExperimentalWarning --importtsx app.ts即通过 tsx 直接启动后端应用属于开发模式服务器。测试默认使用 C 语言配置这是仓库中大多数 e2e 测试如compile.cy.ts、multi-compiler.cy.ts的默认语言。二、运行 Cypress 测试的三种方式服务启动后在另一个终端中即可运行测试。仓库在package.json中预置了以下脚本cypress: cypress run, ts-check:cypress: tsc -p ./cypress/tsconfig.json --noEmit实际使用方式有三种# 1. 运行全部 Cypress 测试无头模式CI 推荐 npm run cypress # 2. 只运行指定测试文件 npm run cypress -- run --spec cypress/e2e/claude-explain.cy.ts # 3. 打开 Cypress 交互式界面开发调试推荐 npm run cypress:open使用交互式界面时选择 E2E Testing 入口再选择目标浏览器Chrome 或 Electron 均可。注意npm run cypress:open等价于直接执行npx cypress open见 docs/UsingCypress.md。除运行测试外仓库还提供了类型检查命令npm run ts-check:cypress它基于 cypress/tsconfig.json继承tsconfig.base.json开启types: [cypress, node]对测试代码做--noEmit类型检查建议在提交测试代码前执行。三、Cypress 配置解析仓库根目录的 cypress.config.ts 是 Cypress 的唯一配置入口import {defineConfig} from cypress; export default defineConfig({ viewportWidth: 1280, viewportHeight: 1024, e2e: { baseUrl: http://127.0.0.1:10240/, supportFile: cypress/support/utils.ts, }, });各配置项含义如下配置项值作用viewportWidth1280测试视口宽度模拟桌面浏览器覆盖TestingTheUi.md中测试各种视口尺寸的基本场景viewportHeight1024测试视口高度e2e.baseUrlhttp://127.0.0.1:10240/所有cy.visit(/)的相对路径都会基于该地址解析10240是本地开发服务器的默认端口e2e.supportFilecypress/support/utils.ts将测试辅助函数文件同时注册为 support 文件使公共工具在测试运行前加载值得注意的是supportFile直接指向 cypress/support/utils.ts这意味着该文件既是工具函数库也被 Cypress 在测试执行前自动加载其顶部import ../../static/global;会引入前端全局类型定义。四、测试组织规范cypress/e2e/目录下共有 13 个测试文件覆盖了 Compiler Explorer 的主要功能面compile.cy.ts基础编译流程与源码-汇编行号联动claude-explain.cy.tsClaude Explain AI 解释功能含 consent、no-ai指令、错误处理multi-compiler.cy.ts多编译器面板操作diff.cy.ts、gccdump.cy.ts、opt-view.cy.ts、pp-view.cy.ts各类视图面板execute.cy.ts、embed.cy.ts、frontend.cy.ts、monaco-test.cy.ts、shortcuts.cy.ts、conformance.cy.ts执行、嵌入、快捷键等其余能力cypress/README.md给出了明确的组织纪律与某个功能强相关的辅助函数helper保留在对应测试文件内部不全局外泄只有真正可跨测试复用的工具才放入cypress/support/utils.ts辅助函数命名要具备自描述性如openClaudeExplainPaneWithOptions一目了然地表明带参数打开面板相关用例用describe块分组同一功能的多个测试复用一致的测试数据。以 cypress/e2e/compile.cy.ts 为例其结构完全遵循上述纪律beforeEach(visitPage)每次测试前全新加载页面afterEach中断言控制台无异常输出assertNoConsoleOutput()用例按describe(Basic compilation)、describe(Source-assembly line linking)分组。五、公共测试工具库速览cypress/support/utils.ts 是仓库沉淀下来的核心测试工具集理解它们能显著降低编写新测试的成本函数用途stubConsoleOutput(win)在页面加载前 stubconsole.log/warn/error配合assertNoConsoleOutput()捕获 JS 异常visitPage()标准beforeEach访问首页并完成控制台 stubwaitForCompilationToSettle()等待进行中的编译到达终态成功/失败图标出现避免编译结果重渲染导致下拉菜单按钮被中途 detachfindPane(titleMatch)按可见的 GoldenLayout 标签标题文本定位面板返回.lm_content内容区sourceEditor()/compilerOutput()获取源码编辑器 / 编译器输出的 Monaco 编辑器setMonacoEditorContent(content, editorIndex)绕过 DOM 输入直接通过 Monaco APImodel.setValue()写入内容随后等待编译结束monacoEditorTextShouldContain(...)断言 Monaco 编辑器.view-lines文本包含并归一化 U00A0 不间断空格setupAndWaitForCompilation()组合式快捷流程等待编辑器 等待编译 settle 断言输出包含squareaddCompilerFromEditor()/addCompilerFromCompilerPane()从源码/编译器面板的 Add new 下拉添加新编译器openExecutor()/openGccDump()/openPreprocessor()/openOptRemarks()通过data-cy选择器打开对应功能面板clearAllIntercepts()清理 Cypress intercept 的兼容工具注意源码注释标明该函数实际并未真正清空 routes仅供claude-explain.cy.ts向后兼容上述工具大量依赖data-cy测试选择器如data-cynew-editor-dropdown-btn、data-cynew-view-explain-btn这是仓库前端组件与测试代码之间的稳定契约写测试时应优先使用data-cy而非脆弱的 CSS class。六、重要测试模式与经验教训cypress/README.md总结了 8 条从实战中沉淀下来的关键经验这也是本文最值得反复阅读的部分。1. 始终使用:visible选择器GoldenLayout 会在 DOM 中创建不可见的模板元素这些元素虽然存在却可能被cy.get()选中导致断言作用于错误的节点。所有涉及 GoldenLayout 面板内容的选择器都应追加:visible// ❌ 错误可能选中模板元素 cy.get(.explain-content).should(contain, text); // ✅ 正确只选中可见元素 cy.get(.explain-content:visible).should(contain, text);这一模式在claude-explain.cy.ts中贯穿始终如cy.get(.explain-consent:visible)、cy.get(span.lm_title:visible)。cypress/support/utils.ts 中的findPane也专门使用span.lm_title:visible来规避模板元素。2. 在afterEach中清理 intercept避免 O(n²) 性能退化Cypress 的 intercept 会在测试之间累积导致后续测试请求匹配越来越慢整体出现 O(n²) 性能退化。正确的清理姿势是在afterEach中清空路由与别名import {clearAllIntercepts} from ../support/utils; afterEach(() { // 方式一使用工具函数 clearAllIntercepts(); // 方式二手动清理 cy.state(routes, []); cy.state(aliases, {}); // ... 其他清理localStorage、sessionStorage 等 });claude-explain.cy.ts的afterEach是标准范例清空routes/aliases后再清理localStorage、sessionStorage并重置win.compilerExplorerOptions确保状态不跨用例泄漏。3. Mock 的建立时机至关重要任何可能触发请求的动作如打开面板、点击按钮之前必须先把对应 API 的 mock 建立好// ❌ 错误面板构造可能已经发出请求mock 来不及生效 openClaudeExplainPane(); mockClaudeExplainAPI(); // ✅ 正确先 mock再触发动作 mockClaudeExplainAPI(); openClaudeExplainPane();claude-explain.cy.ts中的mockClaudeExplainAPI()在页面加载阶段onBeforeLoad钩子就通过win.compilerExplorerOptions.explainApiEndpoint指向http://test.localhost/fake-api/explain随后才打开面板正是这一原则的体现。4. 等待异步 DOM 更新而不只是等待 API 返回cy.wait(getOptions)只能保证请求完成不能保证 DOM 已渲染完毕。更稳健的做法是等待特定的 DOM 状态如加载占位消失// ❌ 错误API 完成但 DOM 可能尚未更新 cy.wait(getOptions); cy.get(.dropdown).select(value); // ✅ 正确先等待加载占位消失再操作 cy.wait(getOptions); cy.get(.dropdown option[valueloading]).should(not.exist); cy.get(.dropdown).select(value);claude-explain.cy.ts中的waitForDropdownsToLoad()正是该模式断言option[valueloading]消失后才继续操作下拉框。5. 使用测试数据而非生产值所有 mock 响应应使用显而易见的假数据如test_first、test_second、focus_a、focus_b避免使用beginner、expert、assembly等真实业务词汇。这样做的收益有三测试输出一眼可辨、不会与真实值混淆、杜绝误触生产 API 的可能。claude-explain.cy.ts中 audience 值统一为test_first/test_second/test_thirdexplanation 类型统一为focus_a/focus_b/focus_c是这一规范的直接体现。6. 提取辅助函数但要分层存放功能专属的辅助函数留在测试文件内通用工具才放support/utils.ts// 测试文件内功能专属 helper function openClaudeExplainPaneWithOptions() { mockClaudeExplainAPI(); openClaudeExplainPane(); cy.wait(getOptions); waitForDropdownsToLoad(); } // utils.ts 中通用 helper export function setMonacoEditorContent(content: string) { ... }compile.cy.ts与claude-explain.cy.ts均从../support/utils导入通用函数同时各自定义功能级 helper分工清晰。7. 认识静态状态与实例状态的差异某些状态是静态的static——在关闭/重开面板后依然存在如 consent、缓存另一些是实例级的——面板关闭即丢失。设计状态应持久化的测试时必须先确认该功能依赖的是哪一类状态。claude-explain.cy.ts中的should remember consent for the session用例就验证了首次同意后关闭面板重新打开时 consent 对话框不再出现静态状态生效。8. 拦截并封锁生产 API为防止测试误触线上服务应显式拦截生产 API 并返回错误这也能在测试早期暴露配置问题cy.intercept(https://api.compiler-explorer.com/**, { statusCode: 500, body: {error: BLOCKED PRODUCTION API}, }).as(blockedProduction);claude-explain.cy.ts的setupClaudeExplainEnvironment()中即有belt and suspenders双保险先clearAllIntercepts()再封锁生产 API随后才注入测试端点配置。七、常见问题与解决方案对照表cypress/README.md将最常见的问题整理成了现象—原因—解法对照表这里完整保留并补充仓库中的实际依据现象原因解决方案测试运行越来越慢intercept 在用例间累积O(n²)在afterEach中调用clearAllIntercepts()或手动cy.state(routes, [])元素明明可见却报 Element not found选中了 GoldenLayout 的模板元素使用:visible伪选择器参考findPane的实现API mock 不生效mock 在请求发出之后才建立在打开面板/触发动作之前完成cy.intercept设置下拉框选择失败异步数据尚未填充完成先等待加载占位如option[valueloading]消失测试中状态未持久化混淆了静态状态与实例级状态确认功能依赖 static 状态如 consent、缓存再编写持久化断言八、调试技巧当测试失败时cypress/README.md给出了五条实用调试路径用cy.log()输出实际拿到的值确认数据与预期是否一致检查 Cypress 命令日志中是否有意外发起的 API 请求关注浏览器控制台报错它们往往暴露了 JS 层面的问题compile.cy.ts正是通过assertNoConsoleOutput()把控制台错误变成测试失败用.then()在特定时间点检查元素状态定位异步时序问题打开浏览器 Network 面板确认请求命中 mock 而非生产环境。此外若怀疑与编译异步流程相关可复用waitForCompilationToSettle()——它专门处理编译结果重渲染导致按钮被 detach这类隐蔽时序问题详见 cypress/support/utils.ts 中该函数的注释说明。九、相关文档与进一步阅读若需系统性地回归验证 UI 各组件可参考仓库内的 docs/TestingTheUi.md 清单它按 Modal、Dropdown、Toast、Popover、Card 等组件类型给出了详细的 UI 验证点测试环境搭建的简要版本可参考 docs/UsingCypress.md。二者的关系是UsingCypress.md解决怎么跑起来cypress/README.md解决怎么写好测试而TestingTheUi.md解决测什么。输出文章赞分享后端前端开发工具【免费下载链接】compiler-explorerRun compilers interactively from your web browser and interact with the assembly项目地址https://gitcode.com/gh_mirrors/co/compiler-explorer点击查看免费下载相关推荐Compiler Explorer 前端 E2E 测试实战使用 Cypress 运行 UI 自动化测试Compiler Explorer 前端 E2E 测试实战使用 Cypress 运行 UI 自动化测试 本篇技术指南以 Compiler Explorer 仓后端前端开发工具终极指南如何使用Playwright为kkFileView构建可靠E2E测试终极指南如何使用Playwright为kkFileView构建可靠E2E测试 kkFileView是一款基于Spring Boot的通用文件在线预览项目为开后端LibrePhotos 前端 E2E 测试贡献指南基于 Cypress Cucumber 的 Gherkin 测试套件实战LibrePhotos 前端 E2E 测试贡献指南基于 Cypress Cucumber 的 Gherkin 测试套件实战 导读 本文围绕 apps/do后端前端移动开发计算机视觉机器学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考