问题修复
用 Verify 快照测试邮件模板,捕捉渲染回归
当需要验证邮件模板(含 MJML)渲染出的 HTML 是否符合已批准的基线、防止模板改动导致意外回归时使用。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
用 Verify 快照测试邮件模板,捕捉通用
解决思路
- 安装快照测试包:dotnet add package Verify.Xunit(或 Verify.NUnit、Verify.MSTest)。
- 编写基础快照测试:从依赖注入获取 IMjmlTemplateRenderer,准备模板变量字典(如 PreviewText、OrganizationName、InviteeName、InviterName、InvitationLink、ExpirationDate),调用 RenderTemplateAsync 渲染模板,再用 await Verify(html, extension: "html") 断言;首次运行会生成 .verified.html 基线文件。
- 模板变更导致测试失败时按以下方式审查差异:用可视化 diff 工具(dotnet tool install -g verify.tool 安装,verify accept 接受所有待处理变更,verify review 打开 diff 工具);在浏览器中打开 .received.html 查看实际渲染效果;利用 IDE 内联 diff 对比 .verified.html 与 .received.html。
- 为每个邮件模板变体分别创建测试:例如 WelcomeEmail_NewUser、WelcomeEmail_InvitedUser、PasswordReset、PaymentReceipt,每个测试提供对应变量并调用渲染,断言时用 .UseMethodName(templateName.Replace("/", "_")) 使快照文件名与模板路径对应。
- 清理动态值以保证快照稳定:使用 .ScrubLinesContaining("Generated at:") 清理含时间戳的行、.ScrubInlineGuids() 清理 URL 中的 GUID;也可自定义清理,如 .ScrubLinesContaining("Date:")、用 AddScrubber 配合 Regex.Replace 把日期 \d{4}-\d{2}-\d{2} 替换为 SCRUBBED-DATE、把 token=[a-zA-Z0-9]+ 替换为 token=SCRUBBED。
- 为邮件测试搭建测试夹具:实现 IAsyncLifetime,在 InitializeAsync 中构建 ServiceCollection,注册内存配置(如 SiteUrl)与 IMjmlTemplateRenderer 实现,最后 BuildServiceProvider,供各测试类通过 IClassFixture 复用。
- 对完整 composer 输出做快照测试:调用 composer.ComposeSignupInvitationAsync 传入收件人邮箱、姓名、邀请人、组织名、邀请链接、过期时间等参数,再用 await Verify(new { email.To, email.Subject, HtmlBody = email.HtmlBody }) 验证包含主题、收件人和正文的完整邮件对象。
- CI 集成:在测试初始化或 ModuleInitializer 中调用 VerifierSettings.ThrowOnMissingVerifiedFile(),使缺少 .verified.html 基线时直接失败,防止意外接受。
- 在 .gitattributes 中添加 *.verified.html linguist-language=HTML 与 *.verified.html diff=html 以改善 diff 处理。
- 遵循最佳实践:为每个模板变体写测试、用描述性测试名(如 PaymentReceipt_WithRefund_ShowsRefundAmount)、一致地清理动态值、接受前用 verify review 仔细审查差异。
- 按工作流执行:创建 MJML 模板 → 编写带示例变量的快照测试 → 首次运行生成 .verified.html → 在浏览器中审查渲染 → 将 .verified.html 提交到版本控制 → 后续改动通过测试失败、审查 diff、确认正确后接受来迭代。
适用边界 · 注意事项
- 不要跳过邮件测试,也不要只测 happy path 或忽略快照测试失败。
- 不要未经审查就自动接受变更(例如 verify accept --all 很危险),应先审查差异。
- 该技能依赖 .NET 与 Verify 生态(Verify.Xunit 等),非 .NET 项目或不使用快照测试的团队不适用。