可观测性【免费下载链接】sentry-javascriptOfficial Sentry SDKs for JavaScript项目地址https://gitcode.com/gh_mirrors/se/sentry-javascript点击查看免费下载导读本篇文章围绕 sentry-javascript 仓库中的端到端E2E测试基础设施展开系统讲解这套测试体系如何把仓库内尚未发布的 SDK 包当作已发布产物来验证其真实行为从本地构建 tarball、注入 pnpm overrides到在 Next.js、Vite、NestJS、Cloudflare Workers 等真实框架应用中运行测试。读完本文你将掌握如何运行、调试、新增和扩展这套 E2E 测试理解其底层链接机制与 CI 矩阵生成逻辑并学会利用标准化测试应用验证跨前后端的分布式追踪链路。这套 E2E 测试在验证什么仓库根目录下的dev-packages/e2e-tests目录承载着一套独立的端到端测试工程。其核心目的正如 README 所述验证仓库中各包在当前状态下发布出去之后的实际表现。与单元测试不同E2E 测试运行在真实的应用框架React、Next.js、Angular、NestJS、Astro、SvelteKit、Cloudflare Workers 等中覆盖 SDK 的初始化、事件上报、路由追踪、分布式追踪等完整链路。需要特别强调的是test-applications目录下的这些测试应用不是示例应用或模板它们可能包含为验证向后兼容而刻意保留的过期或弃用版本的依赖明知存在安全漏洞但有意用于测试的依赖非生产就绪的配置与代码模式。因此官方建议需要示例与最佳实践请查阅 Sentry 官方文档而不是照搬这些测试应用。快速上手如何运行 E2E 测试环境准备运行 E2E 测试的完整流程对应 README 的 How to run 章节如下复制.env.example为.env可选在.env中填写一个示例 Sentry 项目的认证信息——只有需要把数据真正上报到 Sentry 的测试如cloudflare-workers-send-to-sentry才需要可选在.env中填写 Cloudflare 凭据——只有需要部署真实 Cloudflare Worker 的测试才需要。本地运行会部署一个用完即删的临时 worker设置E2E_KEEP_WORKER1可保留它用于调试。CI 则改为每个分支或 PR 保留一个 workerPR 关闭时由cleanup-e2e-workersworkflow 清理在仓库根目录运行yarn build:tarball——每当你修改了/packages下的源码都必须重新执行这一步否则测试应用仍会使用旧构建产物。运行全部测试yarn test:e2e该命令实际上是一串串联任务见 dev-packages/e2e-tests/package.json 的scripts字段test:e2e: run-s test:prepare test:validate test:run依次执行test:prepareprepare.ts 同步 tarball 符号链接→test:validatevalidate-packed-tarball-setup.ts 校验打包环境→test:runrun.ts 逐个运行测试应用。运行单个测试应用yarn test:run app-name也可以指定某个 variantyarn test:run app-name --variant variant-namevariant 名称匹配不区分大小写且支持部分匹配。例如--variant 13会匹配nextjs-pages-dir (next13)前提是该测试应用的package.json中存在对应 variant。在 run.ts 中匹配逻辑实现为variants.find(variant variant.label?.toLowerCase().includes(variantLabelLower))即取第一个 label 包含目标字符串的 variant。使用 Makefile 交互式选择仓库还提供了基于fzf的交互式选择体验见 Makefile前置条件安装fzfbrew install fzf交互式运行测试make run这会弹出一个包含全部测试应用的模糊查找菜单选中后自动运行。其实现是把ls test-applications的结果管道给fzf再交给yarn test:run。列出全部测试应用make list工作原理tarball 符号链接 pnpm overrides理解这套机制是扩展和调试 E2E 测试的基础。整体流程对应 README 的 How they work 章节分为三步打包在仓库根目录运行yarn build:tarball将packages/*下所有sentry/*与sentry-internal/*包npm pack成带版本号的 tarball形如sentry-core-11.0.0.tgz建链接在dev-packages/e2e-tests/packed/目录下创建指向这些版本化 tarball 的无版本号符号链接形如sentry-core-packed.tgz。这一步由test:prepare完成核心实现在 syncPackedTarballSymlinks.ts它会遍历packages/*/package.json为每个存在对应版本 tarball 的包建立packed/name-packed.tgz符号链接若一个链接都没建成功则直接抛错提示先运行yarn build:tarball注入 overrides运行测试时把测试应用复制到临时目录向其package.json或 pnpm 11 的pnpm-workspace.yaml注入 pnpm overrides把所有sentry/*和sentry-internal/*依赖钉死到上述本地 tarball。这样测试应用安装依赖时就像从 registry 安装已发布包一样但实际使用的是本地构建产物——这正是验证包在当前状态发布后的行为的关键。从源码看pnpmOverrides.ts 对 pnpm 版本做了分叉处理pnpm 11overrides 写入package.json的pnpm.overrides字段pnpm ≥ 11pnpm 11 要求 overrides 写在pnpm-workspace.yaml中相关变更见 pnpm 官方 issue脚本会解析并合并已有的 workspace overrides再写回文件同时清理package.json中残留的pnpm字段。另外 run.ts 在运行测试应用前会注入一批环境变量E2E_TEST_DSN默认https://usernamedomain/123、E2E_TEST_SENTRY_ORG_SLUG、E2E_TEST_SENTRY_PROJECT以及SENTRY_E2E_WORKSPACE_ROOT还会设置VOLTA_FEATURE_PNPM1以确保 pnpm 使用应用package.json钉住的 Node 版本。每个测试应用还会获得独立的SENTRY_CONFIG_DIR避免 Sentry CLI 的全局配置和 SQLite 缓存干扰本地构建。validate-packed-tarball-setup.ts则充当打包环境校验器断言存在版本匹配的 tarball、packed/下有符号链接、数量一致且每个符号链接都指向真实存在的文件。如何新增一个测试应用测试应用是完全独立的应用用于验证 SDK 行为对应 README 的 How to set up a new test 章节。新建步骤如下cd dev-packages/e2e-tests mkdir test-applications/my-new-test-application然后在应用package.json中至少提供两个脚本test:build负责安装依赖并构建应用test:assert负责运行测试断言。Sentry 包会在测试时通过注入的 pnpm overrides自动解析到本地构建产物因此无需手动配置 registry。完整的最小示例package.json{ name: my-new-test-application, version: 1.0.0, private: true, scripts: { test: echo \Hello world!\, test:build: pnpm install, test:assert: pnpm test, }, dependencies: { sentry/node: latest || *, }, }关键约束Sentry 依赖的版本说明符必须写成latest || *这样既能兼容普通版本也能兼容预发布版本prerelease。当--variant未命中任何配置时run.ts 会回退到默认的pnpm test:build/pnpm test:assert命令。完成以上步骤后运行yarn test:e2e即可。用sentryTest字段声明 variantstest-applications下的应用会自动被 CI 的job_e2e_tests任务.github/workflows/build.yml拾取测试矩阵由 getTestMatrix.mjs 生成。如需为某个测试应用声明多种构建变体例如不同框架大版本、canary 版本在应用的package.json中添加sentryTest字段sentryTest: { variants: [ { build-command: pnpm test:build-13, label: nextjs-pages-dir (next13) }, { build-command: pnpm test:build-13-canary, label: nextjs-pages-dir (next13-canary) }, { build-command: pnpm test:build-15, label: nextjs-pages-dir (next15) } ] }此时运行yarn test:run nextjs-pages-dir --variant 13会命中第一个匹配的 variant即nextjs-pages-dir (next13)若要精确指定第二个需要写--variant 13-canary。每个 variant 还支持可选的assert-command字段未提供时默认使用pnpm test:assert。从 getTestMatrix.mjs 源码看sentryTest还支持skip跳过该应用、optional标记为可选测试以及optionalVariants可选 variant 列表通过--optionaltrue生成单独矩阵等字段。故障排查与调试对应 README 的 Troubleshooting 章节。常见问题报 Cannot find module sentry/... 或安装到了错误版本重新构建 tarballyarn build yarn build:tarball重新运行yarn test:prepare刷新符号链接删除测试应用的node_modules后重跑测试。本地通过但 CI 失败或反之确认所有sentry/*依赖都使用了latest || *版本说明符检查测试是否依赖了特定于环境的行为。调试技巧开启 SDK debug 模式在 Sentry init 配置中加debug: true查看详细 SDK 日志检查浏览器控制台寻找 SDK 初始化错误或警告检查网络请求确认事件是否发送到了预期 endpoint核对安装的版本cat node_modules/sentry/browser/package.json | grep version。Bundler 特有行为不同打包器处理环境变量与代码替换的方式不同这直接影响测试编写与依赖构建期常量的 SDK 代码对应 README 的 Bundler-Specific Behavior 章节。Webpack用DefinePlugin替换应用代码中的变量不会替换node_modules内的值环境变量必须显式定义。Vitedefine选项替换应用代码中的变量不会替换node_modules内的值import.meta.env.VITE_*变量在构建期被替换需要替换依赖中的值时使用rollup/plugin-replace。Next.js通过 webpack/turbopack自动注入process.env环境变量处理比原生 webpack/Vite 更顺滑服务端与客户端 bundle 对环境变量的访问权限可能不同。import.meta.env注意事项仅在 Vite 与 ES Modules 中可用Webpack 与 Turbopack 没有import.meta.envSDK 代码访问import.meta.env时必须用 try-catch 兜底// Safe pattern for SDK code let envValue: string | undefined; try { envValue import.meta.env.VITE_SOME_VAR; } catch { // import.meta.env not available in this bundler }标准化测试应用复用同一套测试套件为让同一套测试套件跨多种框架/SDK 复用仓库定义了几类标准化测试应用对应 README 的 Standardized Test Apps 章节。标准化前端测试应用注README 中标注该节内容尚未同步更新。标准化前端测试应用应具备以下特征命名前缀统一为standard-frontend-例如standard-frontend-nextjs根路径/页面包含一个idexception-button的input typebutton点击后捕获一个异常且Sentry.captureException()返回的eventId必须写入window.capturedExceptionId一个idnavigation的链接元素点击后导航到/user/5不要求一定是a标签框架自带路由方式亦可关键是元素 id 正确/user/5是一个空页面应用应通过事件处理器把所有 pageload 与 navigation 事务 ID 写入window.recordedTransactionsSentry.addEventProcessor(event { if ( event.type transaction (event.contexts?.trace?.op pageload || event.contexts?.trace?.op navigation) ) { const eventId event.event_id; window.recordedTransactions window.recordedTransactions || []; window.recordedTransactions.push(eventId); } return event; });标准化后端测试应用README 中该节标注为 TBD待补充。标准化前后端Meta-Framework测试应用这类应用用于验证跨前后端的分布式追踪应具备参数化的后端 API 路由/user/:id返回包含用户 ID 的 JSON 对象参数化的前端页面可 SSR/user/:id在客户端从该 API 路由拉取用户数据并展示。这种结构制造了页面加载后立即向后端 API 发请求的场景需要实现以下连接追踪connected tracing测试用例页面加载时的分布式 page load traceHTML meta 标签中应包含 Sentry trace 数据与 baggage服务端根 span 应为客户端 pageload span 的父级所有路由服务端与客户端都应参数化例如/user/5应被捕获为/user/:id路由。客户端请求 API 时的分布式 trace应涉及三个事务客户端 pageload、服务端 pageload、服务端 API 请求客户端 pageload 应包含一个http.clientspan且该 span 是服务端 API 请求 span 的父级三个事务与http.clientspan 应共享同一个trace_id所有transaction名称与span描述都应参数化例如/user/5应被捕获为/user/:id路由。CI 集成按受影响范围动态裁剪矩阵E2E 测试在 CI 中并不是全量盲跑而是基于nx affected做依赖分析对应 README 末尾章节 与 getTestMatrix.mjs对每个测试应用CI 检查其 dependencies 与 devDependencies 中是否有包在当前 PR 内发生了变更例如只改了 browser 包则仅运行依赖 browser 的 E2E 测试应用其余全部跳过getTestMatrix.mjs通过yarn nx show projects --affected计算受影响的包再与各应用sentry*依赖求交集若 E2E 测试共享代码本身发生变更则退化为全部运行或仅运行被改动目录中的应用矩阵以matrix{...}的 JSON 形式输出到 stdout供 GitHub Actions 的job_e2e_tests消费--base参数用于指定对比基线如develop。结语从本地打包到远程 CI这套 E2E 测试基础设施把发布后的真实体验提前到了开发阶段yarn build:tarball产出带版本号的 tarballtest:prepare建立符号链接test:run借助 pnpm overrides 让每个真实框架应用都安装上本地发布版SDK。配合sentryTestvariants 与标准化测试应用无论是单测覆盖不到的多框架兼容问题还是跨前后端的分布式追踪链路都能在合并前被系统性地验证。如果你正在为仓库新增一个 SDK 包或框架集成照着 README 与test-applications/中的现有样例搭建一个最小测试应用是验证行为最直接的方式。赞分享可观测性【免费下载链接】sentry-javascriptOfficial Sentry SDKs for JavaScript项目地址https://gitcode.com/gh_mirrors/se/sentry-javascript点击查看免费下载相关推荐Builder SDK 跨框架 E2E 测试体系Mitosis 应用规格与 Playwright 测试包解析Builder SDK 跨框架 E2E 测试体系Mitosis 应用规格与 Playwright 测试包解析 本文基于 packages/sdks tests前端低代码CMScua-driver 测试框架完全指南从单元测试到跨平台 E2E Harness 的验证体系cua driver 测试框架完全指南从单元测试到跨平台 E2E Harness 的验证体系 cua driver 是 cua 仓库中负责桌面端驱动能力的 R人工智能AI Agent大模型GUI 自动化MCP 服务模型评测微调强化学习工具调用Crossplane 集成测试框架设计解析从 athodyd 提案到现代 E2E 测试体系Crossplane 集成测试框架设计解析从 athodyd 提案到现代 E2E 测试体系 导读 本文围绕 Crossplane 仓库中的设计文档 desig云原生后端上一篇whereami终极再训练指南环境变化时如何快速更新WiFi定位模型下一篇7个步骤搞定AI绘画Krita AI Diffusion完全上手攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Sentry JavaScript 仓库 E2E 测试体系全解析：从 tarball 打包到跨框架测试应用
可观测性【免费下载链接】sentry-javascriptOfficial Sentry SDKs for JavaScript项目地址https://gitcode.com/gh_mirrors/se/sentry-javascript点击查看免费下载导读本篇文章围绕 sentry-javascript 仓库中的端到端E2E测试基础设施展开系统讲解这套测试体系如何把仓库内尚未发布的 SDK 包当作已发布产物来验证其真实行为从本地构建 tarball、注入 pnpm overrides到在 Next.js、Vite、NestJS、Cloudflare Workers 等真实框架应用中运行测试。读完本文你将掌握如何运行、调试、新增和扩展这套 E2E 测试理解其底层链接机制与 CI 矩阵生成逻辑并学会利用标准化测试应用验证跨前后端的分布式追踪链路。这套 E2E 测试在验证什么仓库根目录下的dev-packages/e2e-tests目录承载着一套独立的端到端测试工程。其核心目的正如 README 所述验证仓库中各包在当前状态下发布出去之后的实际表现。与单元测试不同E2E 测试运行在真实的应用框架React、Next.js、Angular、NestJS、Astro、SvelteKit、Cloudflare Workers 等中覆盖 SDK 的初始化、事件上报、路由追踪、分布式追踪等完整链路。需要特别强调的是test-applications目录下的这些测试应用不是示例应用或模板它们可能包含为验证向后兼容而刻意保留的过期或弃用版本的依赖明知存在安全漏洞但有意用于测试的依赖非生产就绪的配置与代码模式。因此官方建议需要示例与最佳实践请查阅 Sentry 官方文档而不是照搬这些测试应用。快速上手如何运行 E2E 测试环境准备运行 E2E 测试的完整流程对应 README 的 How to run 章节如下复制.env.example为.env可选在.env中填写一个示例 Sentry 项目的认证信息——只有需要把数据真正上报到 Sentry 的测试如cloudflare-workers-send-to-sentry才需要可选在.env中填写 Cloudflare 凭据——只有需要部署真实 Cloudflare Worker 的测试才需要。本地运行会部署一个用完即删的临时 worker设置E2E_KEEP_WORKER1可保留它用于调试。CI 则改为每个分支或 PR 保留一个 workerPR 关闭时由cleanup-e2e-workersworkflow 清理在仓库根目录运行yarn build:tarball——每当你修改了/packages下的源码都必须重新执行这一步否则测试应用仍会使用旧构建产物。运行全部测试yarn test:e2e该命令实际上是一串串联任务见 dev-packages/e2e-tests/package.json 的scripts字段test:e2e: run-s test:prepare test:validate test:run依次执行test:prepareprepare.ts 同步 tarball 符号链接→test:validatevalidate-packed-tarball-setup.ts 校验打包环境→test:runrun.ts 逐个运行测试应用。运行单个测试应用yarn test:run app-name也可以指定某个 variantyarn test:run app-name --variant variant-namevariant 名称匹配不区分大小写且支持部分匹配。例如--variant 13会匹配nextjs-pages-dir (next13)前提是该测试应用的package.json中存在对应 variant。在 run.ts 中匹配逻辑实现为variants.find(variant variant.label?.toLowerCase().includes(variantLabelLower))即取第一个 label 包含目标字符串的 variant。使用 Makefile 交互式选择仓库还提供了基于fzf的交互式选择体验见 Makefile前置条件安装fzfbrew install fzf交互式运行测试make run这会弹出一个包含全部测试应用的模糊查找菜单选中后自动运行。其实现是把ls test-applications的结果管道给fzf再交给yarn test:run。列出全部测试应用make list工作原理tarball 符号链接 pnpm overrides理解这套机制是扩展和调试 E2E 测试的基础。整体流程对应 README 的 How they work 章节分为三步打包在仓库根目录运行yarn build:tarball将packages/*下所有sentry/*与sentry-internal/*包npm pack成带版本号的 tarball形如sentry-core-11.0.0.tgz建链接在dev-packages/e2e-tests/packed/目录下创建指向这些版本化 tarball 的无版本号符号链接形如sentry-core-packed.tgz。这一步由test:prepare完成核心实现在 syncPackedTarballSymlinks.ts它会遍历packages/*/package.json为每个存在对应版本 tarball 的包建立packed/name-packed.tgz符号链接若一个链接都没建成功则直接抛错提示先运行yarn build:tarball注入 overrides运行测试时把测试应用复制到临时目录向其package.json或 pnpm 11 的pnpm-workspace.yaml注入 pnpm overrides把所有sentry/*和sentry-internal/*依赖钉死到上述本地 tarball。这样测试应用安装依赖时就像从 registry 安装已发布包一样但实际使用的是本地构建产物——这正是验证包在当前状态发布后的行为的关键。从源码看pnpmOverrides.ts 对 pnpm 版本做了分叉处理pnpm 11overrides 写入package.json的pnpm.overrides字段pnpm ≥ 11pnpm 11 要求 overrides 写在pnpm-workspace.yaml中相关变更见 pnpm 官方 issue脚本会解析并合并已有的 workspace overrides再写回文件同时清理package.json中残留的pnpm字段。另外 run.ts 在运行测试应用前会注入一批环境变量E2E_TEST_DSN默认https://usernamedomain/123、E2E_TEST_SENTRY_ORG_SLUG、E2E_TEST_SENTRY_PROJECT以及SENTRY_E2E_WORKSPACE_ROOT还会设置VOLTA_FEATURE_PNPM1以确保 pnpm 使用应用package.json钉住的 Node 版本。每个测试应用还会获得独立的SENTRY_CONFIG_DIR避免 Sentry CLI 的全局配置和 SQLite 缓存干扰本地构建。validate-packed-tarball-setup.ts则充当打包环境校验器断言存在版本匹配的 tarball、packed/下有符号链接、数量一致且每个符号链接都指向真实存在的文件。如何新增一个测试应用测试应用是完全独立的应用用于验证 SDK 行为对应 README 的 How to set up a new test 章节。新建步骤如下cd dev-packages/e2e-tests mkdir test-applications/my-new-test-application然后在应用package.json中至少提供两个脚本test:build负责安装依赖并构建应用test:assert负责运行测试断言。Sentry 包会在测试时通过注入的 pnpm overrides自动解析到本地构建产物因此无需手动配置 registry。完整的最小示例package.json{ name: my-new-test-application, version: 1.0.0, private: true, scripts: { test: echo \Hello world!\, test:build: pnpm install, test:assert: pnpm test, }, dependencies: { sentry/node: latest || *, }, }关键约束Sentry 依赖的版本说明符必须写成latest || *这样既能兼容普通版本也能兼容预发布版本prerelease。当--variant未命中任何配置时run.ts 会回退到默认的pnpm test:build/pnpm test:assert命令。完成以上步骤后运行yarn test:e2e即可。用sentryTest字段声明 variantstest-applications下的应用会自动被 CI 的job_e2e_tests任务.github/workflows/build.yml拾取测试矩阵由 getTestMatrix.mjs 生成。如需为某个测试应用声明多种构建变体例如不同框架大版本、canary 版本在应用的package.json中添加sentryTest字段sentryTest: { variants: [ { build-command: pnpm test:build-13, label: nextjs-pages-dir (next13) }, { build-command: pnpm test:build-13-canary, label: nextjs-pages-dir (next13-canary) }, { build-command: pnpm test:build-15, label: nextjs-pages-dir (next15) } ] }此时运行yarn test:run nextjs-pages-dir --variant 13会命中第一个匹配的 variant即nextjs-pages-dir (next13)若要精确指定第二个需要写--variant 13-canary。每个 variant 还支持可选的assert-command字段未提供时默认使用pnpm test:assert。从 getTestMatrix.mjs 源码看sentryTest还支持skip跳过该应用、optional标记为可选测试以及optionalVariants可选 variant 列表通过--optionaltrue生成单独矩阵等字段。故障排查与调试对应 README 的 Troubleshooting 章节。常见问题报 Cannot find module sentry/... 或安装到了错误版本重新构建 tarballyarn build yarn build:tarball重新运行yarn test:prepare刷新符号链接删除测试应用的node_modules后重跑测试。本地通过但 CI 失败或反之确认所有sentry/*依赖都使用了latest || *版本说明符检查测试是否依赖了特定于环境的行为。调试技巧开启 SDK debug 模式在 Sentry init 配置中加debug: true查看详细 SDK 日志检查浏览器控制台寻找 SDK 初始化错误或警告检查网络请求确认事件是否发送到了预期 endpoint核对安装的版本cat node_modules/sentry/browser/package.json | grep version。Bundler 特有行为不同打包器处理环境变量与代码替换的方式不同这直接影响测试编写与依赖构建期常量的 SDK 代码对应 README 的 Bundler-Specific Behavior 章节。Webpack用DefinePlugin替换应用代码中的变量不会替换node_modules内的值环境变量必须显式定义。Vitedefine选项替换应用代码中的变量不会替换node_modules内的值import.meta.env.VITE_*变量在构建期被替换需要替换依赖中的值时使用rollup/plugin-replace。Next.js通过 webpack/turbopack自动注入process.env环境变量处理比原生 webpack/Vite 更顺滑服务端与客户端 bundle 对环境变量的访问权限可能不同。import.meta.env注意事项仅在 Vite 与 ES Modules 中可用Webpack 与 Turbopack 没有import.meta.envSDK 代码访问import.meta.env时必须用 try-catch 兜底// Safe pattern for SDK code let envValue: string | undefined; try { envValue import.meta.env.VITE_SOME_VAR; } catch { // import.meta.env not available in this bundler }标准化测试应用复用同一套测试套件为让同一套测试套件跨多种框架/SDK 复用仓库定义了几类标准化测试应用对应 README 的 Standardized Test Apps 章节。标准化前端测试应用注README 中标注该节内容尚未同步更新。标准化前端测试应用应具备以下特征命名前缀统一为standard-frontend-例如standard-frontend-nextjs根路径/页面包含一个idexception-button的input typebutton点击后捕获一个异常且Sentry.captureException()返回的eventId必须写入window.capturedExceptionId一个idnavigation的链接元素点击后导航到/user/5不要求一定是a标签框架自带路由方式亦可关键是元素 id 正确/user/5是一个空页面应用应通过事件处理器把所有 pageload 与 navigation 事务 ID 写入window.recordedTransactionsSentry.addEventProcessor(event { if ( event.type transaction (event.contexts?.trace?.op pageload || event.contexts?.trace?.op navigation) ) { const eventId event.event_id; window.recordedTransactions window.recordedTransactions || []; window.recordedTransactions.push(eventId); } return event; });标准化后端测试应用README 中该节标注为 TBD待补充。标准化前后端Meta-Framework测试应用这类应用用于验证跨前后端的分布式追踪应具备参数化的后端 API 路由/user/:id返回包含用户 ID 的 JSON 对象参数化的前端页面可 SSR/user/:id在客户端从该 API 路由拉取用户数据并展示。这种结构制造了页面加载后立即向后端 API 发请求的场景需要实现以下连接追踪connected tracing测试用例页面加载时的分布式 page load traceHTML meta 标签中应包含 Sentry trace 数据与 baggage服务端根 span 应为客户端 pageload span 的父级所有路由服务端与客户端都应参数化例如/user/5应被捕获为/user/:id路由。客户端请求 API 时的分布式 trace应涉及三个事务客户端 pageload、服务端 pageload、服务端 API 请求客户端 pageload 应包含一个http.clientspan且该 span 是服务端 API 请求 span 的父级三个事务与http.clientspan 应共享同一个trace_id所有transaction名称与span描述都应参数化例如/user/5应被捕获为/user/:id路由。CI 集成按受影响范围动态裁剪矩阵E2E 测试在 CI 中并不是全量盲跑而是基于nx affected做依赖分析对应 README 末尾章节 与 getTestMatrix.mjs对每个测试应用CI 检查其 dependencies 与 devDependencies 中是否有包在当前 PR 内发生了变更例如只改了 browser 包则仅运行依赖 browser 的 E2E 测试应用其余全部跳过getTestMatrix.mjs通过yarn nx show projects --affected计算受影响的包再与各应用sentry*依赖求交集若 E2E 测试共享代码本身发生变更则退化为全部运行或仅运行被改动目录中的应用矩阵以matrix{...}的 JSON 形式输出到 stdout供 GitHub Actions 的job_e2e_tests消费--base参数用于指定对比基线如develop。结语从本地打包到远程 CI这套 E2E 测试基础设施把发布后的真实体验提前到了开发阶段yarn build:tarball产出带版本号的 tarballtest:prepare建立符号链接test:run借助 pnpm overrides 让每个真实框架应用都安装上本地发布版SDK。配合sentryTestvariants 与标准化测试应用无论是单测覆盖不到的多框架兼容问题还是跨前后端的分布式追踪链路都能在合并前被系统性地验证。如果你正在为仓库新增一个 SDK 包或框架集成照着 README 与test-applications/中的现有样例搭建一个最小测试应用是验证行为最直接的方式。赞分享可观测性【免费下载链接】sentry-javascriptOfficial Sentry SDKs for JavaScript项目地址https://gitcode.com/gh_mirrors/se/sentry-javascript点击查看免费下载相关推荐Builder SDK 跨框架 E2E 测试体系Mitosis 应用规格与 Playwright 测试包解析Builder SDK 跨框架 E2E 测试体系Mitosis 应用规格与 Playwright 测试包解析 本文基于 packages/sdks tests前端低代码CMScua-driver 测试框架完全指南从单元测试到跨平台 E2E Harness 的验证体系cua driver 测试框架完全指南从单元测试到跨平台 E2E Harness 的验证体系 cua driver 是 cua 仓库中负责桌面端驱动能力的 R人工智能AI Agent大模型GUI 自动化MCP 服务模型评测微调强化学习工具调用Crossplane 集成测试框架设计解析从 athodyd 提案到现代 E2E 测试体系Crossplane 集成测试框架设计解析从 athodyd 提案到现代 E2E 测试体系 导读 本文围绕 Crossplane 仓库中的设计文档 desig云原生后端上一篇whereami终极再训练指南环境变化时如何快速更新WiFi定位模型下一篇7个步骤搞定AI绘画Krita AI Diffusion完全上手攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
