端到端测试为何要看见 UI 之外？用 dánwò 检查 Agent 写出的应用
界面测试通过，不代表业务真的正确。结账按钮显示“支付成功”，后台却可能重复扣款；页面提示注册成功，欢迎邮件却没有发出。尤其当 AI 编码 Agent 快速生成接口、Webhook 和重试逻辑时，只断言屏幕上的文字，很容易漏掉跨系统副作用。
开源项目 dánwò（Apache-2.0，TypeScript）试图把这类验证纳入端到端测试：像用户一样驱动 Web 或移动端界面，再按需检查应用背后的数据库与外部服务。它并非“让模型替你判断一切”的测试框架；核心思路是把 UI 行为、可验证的不变量和可复现故障组合起来。
先从不依赖模型的 UI 测试开始
dánwò 提供定位器式测试。下面是项目 README 展示的简化用例：
import { test } from "@danwo/sdk"
test("注册成功后显示欢迎信息", async ({ app, screen, expect }) => {
await app.open("/sign-up")
await screen.getByLabel("Email").fill("ada@example.com")
await screen.getByLabel("Password").fill("correct horse battery staple")
await screen.getByRole("button", { name: "Create account" }).click()
await expect(screen.getByRole("heading", { name: "Welcome, Ada" })).toBeVisible()
})
这类断言不需要模型或 API key。项目也支持自然语言步骤：首次运行时由模型把描述映射为界面操作，随后记录动作可重放；README 特别提到 danwo test --replay-only 可在 CI 中强制只重放，避免 CI 调用模型。界面变化导致记录不再适用时，测试才需要重新解析步骤。
这让“探索”与“回归”可以分开：开发阶段可用 Agent 更快编写测试，持续集成则优先执行可重复的记录。但重放并不意味着测试永不维护——页面结构或交互变化时，仍需检查记录是否准确。
把后端结果写成不变量
涉及支付、邮件和 Webhook 时，测试不仅要问“页面显示了什么”，还应核对“系统最终发生了什么”。dánwò 的后端层包含服务模拟、测试后不变量检查，以及故障注入矩阵。
例如，一个注册流程可以用不变量核实数据库中只有一条记录、邮件服务中只有一封欢迎邮件。这样即便界面只显示一次成功提示，隐藏的重复提交也会让检查失败。README 展示的服务模拟覆盖 Stripe、Clerk、Resend、Google、Slack 等，并称总计还包括 20 多种服务；请求经代理路由到本地模拟器，目标是减少沙箱密钥和应用代码改动。具体模拟保真度仍有边界，项目也说明模拟器不能覆盖真实提供商 API 的所有细节。
danwo matrix 则会针对测试中可能遇到的故障重复运行用例。项目列举了服务端 500/429、支付拒绝、重复 Webhook、数据库提交响应丢失等情况，再由不变量判断系统是否仍满足业务约束。其价值在于将“错误路径是否安全”从临时手工操作变成可重复场景，而不是证明系统面对所有现实故障都无懈可击。
一个适合渐进采用的流程
官方 README 给出的快速启动命令是：
npx @danwo/cli init npm run test:danwo
项目要求 Node.js 22.22.3 或更高的 22.x 版本，或 24.11.1 及以上 24.x；README 还说明 Web 测试可在 macOS、Linux、Windows 运行，移动端测试需要 macOS 或 Linux。init 会询问要测试的对象、模型/服务提供商以及编码 Agent 配置，并生成初始配置和测试。该命令是项目文档中的入口，实际仓库较新，使用前应查看快速入门文档确认当前依赖与配置细节。
可以按以下顺序试用：
- 先用定位器覆盖关键 UI 路径，避免一开始就引入模型依赖。
- 对支付、发信、积分发放等副作用定义可查询的不变量，明确“成功”应留下哪些持久结果。
- 将最关键的测试加入故障矩阵，重点检查重复请求、超时和提供商拒绝等边界。
- 在 CI 中采用记录重放，并在升级应用或测试框架后检查记录是否仍代表真实用户流程。
项目支持 Chromium、Firefox、WebKit，以及 Android 模拟器和 iOS Simulator；README 还列有 Playwright、Cypress、Detox 的迁移路径。不过，部署和后端代理能力存在运行时边界：HN 项目说明指出后端路由目前面向 Node 与 Bun。团队应先确认自身技术栈、模拟器覆盖和移动端环境，再决定是否接入整个后端层。
适用边界比功能清单更重要
dánwò 的特点不是单纯“让 AI 写更多测试”，而是把 Agent 生成的 UI 流程纳入可重放测试，并尝试验证界面背后的外部副作用。对有支付、通知或异步任务的应用，这种分层检查能补上纯 UI 断言的盲点。
另一方面，模拟服务与真实服务不可能完全等价；核心业务不变量需要开发者自己定义，且初期项目的 API 可能变化。较稳妥的做法，是先挑选一条高风险链路做试点：确保 UI、数据库和外部效果三者都有明确断言，再评估故障矩阵能否融入现有 CI。测试工具可以揭露系统的盲区，却不能替代对业务语义和真实服务行为的确认。
相关链接