你的應用程式帶有證據
Kliv 為其建置的應用程式編寫真實的測試 — 並在真實的瀏覽器中針對資料庫的一次性副本執行它們，並提供每個副作用的收據。編寫應用程式的相同迴圈編寫其測試並將其驅動為綠色。
內建測試
未產生程式碼並交叉手指
大多數 AI 建置者都會產生一個應用程式並將其移交 — 它是否真正有效是你的問題。 Kliv 擁有應用程式執行的整個堆疊：瀏覽器、API、安全規則、資料庫、電子郵件管道。這就是證明成為可能的原因。測驗不是事後才進行的，而是事後才進行的。它們是應用程式建置方式的一部分，透過編寫程式碼的相同迴圈執行。
跑步的解剖
瞭解測試系統的最佳方法是追蹤從第一行到結論的執行。這就是所發生的事情——而且永遠不會觸及你的真實資料。
寫
AI 在建置時編寫單元測試 — 真正的 Vitest 和測試函式庫，業界標準堆疊，而不是專有的模仿品。要求覆蓋一個流程，它會寫一個 Scenario：導航、點選、填充、斷言，用語義術語來說——按鈕按其名稱，欄位按其標籤——而不是在下一次重新設計中消失的脆弱 CSS 路徑。
在真實瀏覽器中執行
在真實的瀏覽器中針對你的實際應用程式執行測試 — 真實渲染、真實登入、真實行級安全性。沒有什麼是重要的：如果權限更改允許一個使用者讀取另一個使用者的資料，那麼測試就會像你的應用程式那樣失敗。
分叉資料庫
在 Scenario 接觸資料之前，它會獲得資料庫的一次性分支 — 相同的模式，相同的規則，沒有任何行面臨風險。建置、編輯和刪除真實執行並降落在叉子上；你的檔案和商業狀態以相同的方式克隆。當跑步結束時，叉子被扔掉。
捕獲出口
電子郵件、網路鉤子和第三方呼叫將被捕獲，而不是觸發。測試可以斷言歡迎電子郵件已發出，傳送給誰，傳送了什麼內容，並且沒有電子郵件離開建築物。當你的邏輯得到鍛鍊時，你的整合保持安靜。
收據
每次執行都會記錄應用程式實際執行的操作：它寫入了哪些行，它會傳送哪些電子郵件，它嘗試了哪些外部呼叫 — 每個呼叫都標記為接受、捕獲或拒絕，並附加原因，直至阻止寫入的安全規則。不僅僅是紅色或綠色：發生了什麼以及為什麼。
判決結果
每次檢查、每個檔案都會傳回結果 — 失敗的斷言、損壞的步驟以及執行收據。結構化故障是重點：它讓編寫程式碼的相同迴圈找到錯誤，修復它，然後再次執行。
大門
測試結果門發布。失敗的 Scenario 在釋出到達你的使用者之前會停止發布 — 因此“我們建置它時它可以工作”變成“現在它可以工作”，在每次更改時進行驗證，而不是從演示中記住。
測試系統知道如何做
內建，為你執行，並且在你想檢視時即可讀取。
真正的測試堆疊
在瀏覽器中執行的正版 Vitest、測試庫和 jest-dom — 與專業團隊使用的工具相同，因此測試讀起來就像測試，而不像供應商的方言。
Scenario 測試
用語義術語編寫的端對端流程 — 透過其角色找到按鈕，透過其標籤找到欄位 — 以使用者的方式驅動真正的應用程式。
一次性資料庫
每個 Scenario 都針對真實資料庫的一個分支執行。寫入被接受、斷言和丟棄——你的資料永遠不是實驗的一部分。
沒有洩漏
測試執行捕獲電子郵件、網路鉤子和聯結器呼叫，而不是傳送它們 — 你可以證明它們已經發生，而無需它們發生。
每次跑步都有收據
測試引起的每一個副作用的分類帳——接受、捕獲或拒絕，並附上原因。痕跡，而不僅僅是紅綠燈。
歷史與大門
隨著時間的推移，追蹤執行情況，透過測試即可發布——驗證是應用程式的一種靜態狀態，而不是一次性事件。
常見問題
誰寫測試？
AI 在建置時預設在標準堆疊中進行單元測試。請求覆寫一個流程，它會為其寫入 Scenario。每個測試都是應用程式中可讀的程式碼；你可以檢查其中任何一個，而且你永遠不必這樣做。
測試會觸及我的真實資料嗎？
不會。Scenario 針對資料庫的一次性分叉執行 — 在那裡接受寫入，並在執行結束時與分叉一起丟棄。檔案和商業狀態的克隆方式相同，因此即使刪除所有內容的測試也不會刪除任何內容。
測試會傳送真實的電子郵件還是會影響我的整合？
否 — 出站流量被捕獲，而不是傳送。執行記錄了電子郵件將傳送給誰以及傳送的內容，並且測試可以對其進行斷言。你的客戶和連線的工具永遠不會看到測試。
當測試失敗時我會看到什麼？
每次檢查結果 — 檔案、檢查、失敗的斷言 — 加上執行收到的副作用以及每個副作用被允許或拒絕的原因。這種結構讓 AI 能夠診斷自己的錯誤並修復它，而不是根據螢幕截圖進行猜測。
測試是否執行我的安全規則？
是的 — Scenario 根據真實的行級規則進行真實登入，而不是模擬會話。如果變更讓使用者看到不屬於他們的資料，則測試會先於使用者失敗。
失敗的測試會阻止發布嗎？
是的。 Scenario 判定門發布 — 紅色執行會停止發布，直到再次變為綠色。門是希望最後一次更改是安全的和知道它已被檢查之間的區別。
