内置测试
未生成代码并交叉手指
大多数 AI 构建者都会生成一个应用并将其交给，它是否真正有效是你的问题。 Kliv 拥有应用运行的整个堆栈：浏览器、API、安全规则、数据库、电子邮件管道。这就是证明成为可能的原因。测试不是事后才进行的，而是事后才进行的。它们是应用构建方式的一部分，通过编写代码的同一循环运行。
跑步的解剖
了解测试系统的最佳方法是跟踪从第一行到结论的运行。以下是，发生的情况以及从未触及你的真实数据的情况。
写
AI 在构建，真正的 Vitest 和测试库时编写单元测试，这是行业标准堆栈，而不是专有的模仿品。要求覆盖一个流程，它会写一个 Scenario：导航、点击、填充、断言，用语义术语，按钮按其名称，字段按其标签，不是在下一次重新设计中消失的脆弱 CSS 路径。
在真实浏览器中运行
在真实浏览器中针对你的实际应用，真实渲染、真实登录、真实行级安全性执行测试。没有什么是重要的：如果权限更改允许一个用户读取另一个用户的数据，那么测试就会像你的应用那样失败。
分叉数据库
在 Scenario 接触数据之前，它会获得数据库，的一次性分支，相同的模式，相同的规则，没有任何行面临风险。创建、编辑和删除真实运行并降落在叉子上；你的文件和商业状态以相同的方式克隆。当跑步结束时，叉子被扔掉。
捕获出口
电子邮件、webhook和第三方调用将被捕获，而不是被触发。测试可以断言欢迎电子邮件已发送给谁、发送了什么内容，并且没有电子邮件离开建筑物。当你的逻辑得到锻炼时，你的集成保持安静。
收据
每次运行都会记录应用实际执行的操作：它写入了哪些行，它将发送哪些电子邮件，它尝试了哪些外部调用，每个调用都标记为接受、捕获或拒绝，并附加原因，直至阻止写入的安全规则。不仅仅是红色或绿色：发生了什么以及为什么。
判决结果
每次检查、每个文件，都会返回失败的断言、损坏的步骤以及运行收据的结果。结构化故障是重点：它让编写代码的同一循环找到错误，修复它，然后再次运行。
大门
测试结果门发布。失败的 Scenario 在到达你的用户，之前会停止发布，因此“我们构建它时它可以工作”变成“现在它可以工作”，在每次更改时进行验证，而不是从演示中记住。
测试系统知道如何做什么
内置，为你运行，并且在你想查看时即可读取。
真正的测试堆栈
在浏览器，中运行的正版 Vitest、测试库和 jest-dom 与专业团队使用的工具相同，因此测试读起来就像测试，而不像供应商的方言。
Scenario 测试
以语义术语，编写的端到端流程按其角色查找按钮，按其标签，查找字段，以用户的方式驱动真实应用。
一次性数据库
每个 Scenario 都针对真实数据库的一个分支运行。写入被接受、断言并丢弃，你的数据永远不是实验的一部分。
没有泄漏
测试运行捕获电子邮件、webhook和连接器调用，而不是发送它们，你可以证明它们已经发生，而无需它们发生。
每次跑步都有收据
测试导致，接受、捕获或拒绝的每个副作用的分类帐，并附有原因。痕迹，而不仅仅是红绿灯。
历史与大门
随着时间的推移跟踪运行，通过测试门发布，验证是应用的一种长期状态，而不是一次性事件。
常见问题
谁编写测试？
AI 会这样做，因为它默认在标准堆栈中构建，单元测试。要求覆盖一个流程，它会为其写入 Scenario。每个测试都是应用中可读的代码；你可以检查其中任何一个，而且你永远不必这样做。
测试会触及我的真实数据吗？
不会。针对数据库的一次性分支运行的场景，写入会被接受，并在运行结束时与分支一起丢弃。文件和商业状态的克隆方式相同，因此即使删除所有内容的测试也不会删除任何内容。
测试会发送真实的电子邮件还是会影响我的集成？
不会捕获或发送任何，出站流量。运行记录了电子邮件将发出的信息、发送给谁以及发送的内容，并且测试可以对其进行断言。你的客户和连接的工具永远不会看到测试。
当测试失败时我会看到什么？
每次检查结果，文件、检查、，失败的断言加上运行收到的副作用以及每个被允许或拒绝的原因。这种结构可以让 AI 诊断自己的错误并修复它，而不是根据屏幕截图进行猜测。
测试是否执行我的安全规则？
是的，场景根据真实的行级规则运行真实登录，而不是模拟会话。如果更改让用户看到不属于他们的数据，则测试会先于用户失败。
失败的测试会阻止发布吗？
是的。 Scenario 判决门发布，红色运行停止发布，直到再次变为绿色。门是希望最后一次更改是安全的和知道它已被检查之间的区别。
