Vaadin 推出无浏览器测试，可毫秒级验证 AI 生成的 Web 应用

AI 编码 agent 写代码很快。瓶颈不再是打字，而是验证。agent 多快能发现它刚写的代码是正确的？这正是测试速度和测试架构突然变得前所未有的重要的原因。

借助 Vaadin Browserless Testing，我可以编写包含 UI 代码的完整集成测试，而且这些测试在毫秒级而不是秒级运行。不需要浏览器，不需要 Web 服务器。在这篇文章中，我将解释为什么这是一个游戏规则改变者，尤其是与经典的 JavaScript SPA 加 Java 后端架构相比。

使用 React 或 Angular 前端加 Java 后端时，UI 逻辑存在于不同的语言和不同的进程中。结果是两个测试世界： 三层测试、三套工具链，而且没有合并的覆盖率数字。

最糟糕的部分是：前端和后端之间的契约只由最慢、最脆弱的一层覆盖，即端到端测试。而大多数 bug 恰恰就出在这个契约上。DTO 中重命名的字段、更改的验证规则、不同的日期格式。前端单元测试抓不到它，因为 API 是被 mock 的。后端测试抓不到它，因为它们不了解前端。只有 e2e 测试会失败，几分钟后才失败，如果那天它不 flaky 的话。

使用 Vaadin Flow，UI 是服务端 Java。视图在同一个 JVM 中直接调用服务。Vaadin Browserless Testing 让我无需启动浏览器或 Web 服务器就能测试这棵组件树。

一个测试就能覆盖整个流程：按钮点击、binder 验证、服务调用，以及针对数据库的 jOOQ 查询。该测试继承 browserless-test-spring 依赖中的 SpringBrowserlessTest，并且 @SpringBootTest 为它提供完整的应用上下文。下面是一个典型测试的样子： class CustomerViewTest extends SpringBrowserlessTest { void createCustomer() { CustomerView view = navigate(CustomerView.class); test(view.name).setValue("Martinelli LLC"); test(view.save).click(); Notification notification = find(Notification.class).single(); assertThat(test(notification).getText()).contains("Customer saved"); 这不是对 UI 的 mock。这是真实的组件树、真实的 binder、真实的服务、真实的 SQL。它只是没有浏览器也能运行。这样的测试在毫秒级运行。一个可比的 Playwright 测试需要几秒钟，再加上应用和浏览器的启动时间。

当一个测试在毫秒级运行，agent 可以在每次更改后运行整个测试套件。循环变成：写视图、运行测试、看到失败、修复它。全部在一次迭代内完成。

使用基于浏览器的测试，这个循环需要几分钟。更糟的是，agent 会在 flaky 失败上消耗 token：时序问题、缺失的等待、要分析的截图。Browserless 测试是确定性的，因为一切都在同一个 JVM 中运行。当测试失败时，就是代码错了。不是时序，不是网络，是代码。

还有第二个很多人忽略的效果：代码覆盖率。

使用 Playwright 时，UI 在单独的服务器进程中运行。JaCoCo 看不到视图层的任何内容。你的覆盖率报告会把视图显示为未测试，即使 e2e 套件覆盖了它们。要得到真实的数字，你必须跨进程和语言合并 JaCoCo 和 Istanbul 报告。没人这么做。

使用 Browserless Testing，视图、binder 和监听器都在测试 JVM 中执行。JaCoCo 像对待任何其他类一样对它们进行插桩。我为整个应用得到一个诚实的覆盖率数字：UI、服务和 jOOQ repository 一起计算。

这对 AI 工作流也很重要。如果我告诉 agent“覆盖率必须保持在 80% 以上”，JaCoCo 实际上可以在构建中强制执行这一点，因为 UI 代码也计入。

agent 只需要 Java、JUnit 和 Maven 或 Gradle。不需要 Node，CI 中不需要浏览器二进制文件，Playwright 容器和应用之间没有版本漂移。

而且 agent 不必保持两个代码库一致。使用 SPA 时，每次更改都会触及两端：TypeScript 类型、DTO、API 客户端、端点。不匹配只会在慢速的 e2e 层暴露出来。使用 Vaadin 时，编译器已经能捕获不匹配，而 Browserless 测试在毫秒级证明整个流程。

让我们看看支持 SPA 架构的常见论点：

“我们反正需要一个 API。”这混淆了两个关注点。用于客户端-服务器通信的 API 和公共 API 是不同的东西，有不同的需求。内部的 API 随着每次 UI 迭代而变化。公共 API 需要版本化、稳定性和文档。将内部 REST API 作为公共 API 暴露的团队通常会后悔。你可以构建一个 Vaadin 应用，同时在其旁边提供一个干净的公共 API，为真实消费者设计。

“我们有一个前端团队。”拆分的历史原因是专业化：JavaScript 人和 Java 人。但 AI agent 不在乎这个边界。它写 Java 视图和写 React 组件一样容易。agent 在乎的是反馈速度和一致性，而在那里，单一生态系统明显胜出。SPA 拆分保留了两个代码库之间的协调开销，但不再提供当初证明其合理的专业化收益。

“我们需要离线支持。”这个论点有效。如果你的客户端必须离线工作，你需要客户端逻辑和 SPA 或原生应用。但说实话：有多少业务应用真的需要这个？

对于典型的业务应用，使用 Vaadin、Spring Boot 和 jOOQ 的统一技术栈现在拥有的测试能力是 SPA 架构无法匹敌的：

我仍然为关键用户流程编写一小套 Playwright 旅程测试。但我测试套件的主力是 Browserless Testing。对于 AI 生成的项目，这不仅仅是方便。它改变了可能性，因为 agent 可以以它写代码的速度验证自己的工作。