2026 Bun 1.4.4 --changed 跳过邮件验证测试怎么办？

先核对变更基准：--changed 到底比较了什么？

Bun 1.4 对 bun test --changed 的说明是：根据 Git 报告的改动文件，筛选受影响的测试文件。没有指定比较对象时，它针对未提交改动；也可以用 --changed=main 或某个提交，明确指定比较分支或提交。运行器会扫描测试文件的导入关系，再反向查找能到达变更文件的测试。(Bun 1.4 发布说明)

所以，看到 bun test --changed 退出成功，只能说明这次命令没有以失败状态结束；不能据此推断所有邮件相关用例都运行过。CI 与本地如果使用不同的比较基准，或检出的分支、提交状态不同，得到的候选测试也可能不同。核验时先看实际命令和 Git diff，不要把某次本地输出当成 CI 的证据。

git status --short
git diff --name-only
git diff --name-only origin/main...HEAD
bun --version
bun test --changed=origin/main

这些命令分别帮助检查工作区状态、当前差异、与远端基准的提交差异、Bun 版本和指定基准下的增量测试结果。实际项目若以其他分支或提交为基准，应将 origin/main 换成 CI 配置中的真实比较对象；Bun 官方示例也支持用分支或提交作为 --changed 的比较目标。

查清变更关联：邮件代码与测试的可识别关系

邮件模板、注册处理逻辑和验证链接处理代码，不一定都处在同一条直接导入链上。举例来说，测试直接导入注册处理函数，处理函数再导入邮件模板模块时，模板改动有机会沿可识别的依赖关系关联到相应测试。Bun 对机制的描述是扫描测试文件的导入，并从变更文件沿导入图反向寻找相关测试；因此，测试文件是否被选中，取决于它与改动之间能否建立这条关系。

配置文件、生成文件、运行时拼装的路径或间接触发的依赖，则需要谨慎处理。不要仅凭“这个模块运行时会用到”就假定筛选器一定能从它推导出对应测试；应先检查项目里的实际导入边界和本次输出。这个提醒是根据官方公布的导入图机制作出的工程判断，并非 Bun 对所有动态依赖场景的保证。

对于关键回归路径，更稳妥的做法是给测试任务一个明确入口，例如专门的集成测试脚本或 CI job。即使某次增量筛选没有选中它，也能通过独立任务运行注册、发送验证邮件及消费验证链接的用例，而不是寄希望于改动碰巧触发导入图。

核对实际选取：邮件测试文件和用例是否出现在输出里？

不要只看“命令成功”或绿色状态。对照本次变更文件，逐项确认相关测试文件是否出现在 Bun 输出或 CI 测试报告中；必要时再核对测试名称，确保运行的不是同文件内与邮件流程无关的其他用例。Bun 的测试文档介绍了测试运行器的执行与报告选项，团队应据此核对自己实际配置的结果。(Bun 测试文档)

bun test --changed=origin/main
bun test ./tests/registration-email.test.ts

第一条用于查看指定比较基准下的增量结果；第二条是直接运行邮件测试文件的示例，路径应替换为项目中的实际文件。若 CI 通过 JUnit 保存报告，应从报告确认文件与用例确实执行，而不是仅凭 job 结束状态推测覆盖完整。Bun 文档说明了 JUnit 报告参数及输出文件配置方式；是否适用于团队现有流水线，还应按项目配置核实。(Bun 测试配置文档)

验证应用流程：区分各类断言能证明的结果

邮件相关测试通常至少需要分开观察三个结果：应用有没有生成预期邮件内容；验证链接或验证码断言是否符合预期；验证完成后，账号状态是否按设计变化。若邮件发送组件在测试中被 mock，测试通过可以证明应用调用了该组件并构造了符合断言的内容，但不能证明外部邮件服务已投递。

应用层测试也可能只验证链接格式或验证码参数，没有真正消费链接、检查失效条件或核对账号状态。建议把这些断言对应到团队定义的产品行为：模板变更至少核对主题、正文和关键链接；注册逻辑变更核对收件地址与账号状态；链接处理变更核对验证结果及状态更新。具体断言应与自家产品的实现和安全要求一致，不要把示例当作通用完整清单。

若邮件验证码没有按预期进入受控收件环境，应分别排查测试流程与收件链路，不要先把问题归因于 --changed。可以参考我们的验证码延迟排查指南，把应用是否调用发送流程、收件环境是否可读拆成不同检查项。

选择执行路径：什么时候增量测试够用，什么时候要补跑？

按目标选择执行策略，而不是在每次提交后都把增量结果当作发布依据：

• 若目标是本地快速反馈，且本次改动与邮件测试之间有清晰、可核对的导入关系：运行 bun test --changed=<比较基准>，然后确认输出中实际出现了相关测试文件与用例。
• 若邮件代码依赖配置、生成内容或运行时拼装，无法从输出确认关联：不要用推测补足证据；直接运行对应邮件测试文件或专用集成测试任务。
• 若目标是合并或发布验收：让 CI 中存在明确覆盖邮件关键路径的任务，并核对 job 命令、比较基准和报告中的实际用例；增量任务可以保留作快速反馈，但不替代明确的回归验收。
• 若验收要求证明邮件真实可读：在自家产品或获授权环境中使用隔离的受控收件地址，再查看邮件内容与本次测试是否对应。运行器选取、应用断言和收件结果应分开记录。

--changed 的价值在于按 Git 变更与测试导入关系缩小执行范围；Bun v1.3.13 的发布说明也按这一机制描述了该功能。它适合提供增量反馈，不应被写成“完整邮件回归”或“真实投递成功”的同义词。(Bun v1.3.13 发布说明)

区分真实收件：真实可读的证据边界

真实收件验收应在隔离的测试环境中进行，并使用专门用于自家产品测试的收件地址。核对邮件主题、正文、链接或验证码是否与本次测试对应，同时记录测试环境和应用侧结果。真实收件只能证明这次邮件在所用收件环境中的观察结果；不能据此承诺其他地址、其他邮件服务或后续发送也必然成功。

测试邮件里也应避免放入真实用户的个人信息。使用虚构测试身份、专用环境和受控收件地址，能减少开发与演示过程把真实信息带入测试报告或团队邮箱的风险。关于测试数据处理，可以进一步阅读我们的测试数据与隐私说明；若评估收件方式，也可查看临时邮箱与真实邮箱的差异。

若只是开发阶段临时注册、试用或接收一次验证邮件，Inboxonce 可以作为受控收件方案之一：免注册、即开即用，不必把测试邮件塞进主邮箱，也能避免测试通知持续干扰日常收件。需要长期找回、回信或持续收信的重要账户，仍应使用自己可长期管理的邮箱；需要核验邮件是否实际可读取时，再根据测试环境选择合适的临时收件方式。