アプリには証拠が付属します
Klivは、構築するアプリの実際のテストを作成し、実際のブラウザでデータベースの使い捨てコピーに対して実行し、すべての副作用のレシートを作成します。アプリを作成するのと同じループがテストを作成し、それらをグリーンにします。
組み込みのテスト
コードが生成されていない、問題が発生している
ほとんどのAIビルダーはアプリを生成して渡しますが、それが実際に機能するかどうかはあなたの問題です。 Klivは、アプリが実行されるスタック全体 (ブラウザー、API、セキュリティルール、データベース、メール パイプライン) を所有します。それによって証明が可能になるのです。テストは後から追加するものではありません。これらはアプリの構築方法の一部であり、コードを記述したのと同じループによって実行されます。
ランニングの構造
テスト システムを理解する最良の方法は、最初の行から判定まで 1回の実行を追跡することです。ここで何が起こるのか、そして実際のデータには決して触れないことが起こります。
書く
AIは、ビルド時に単体テストを作成します。これは、独自の模造品ではなく、業界標準のスタックである本物の Vitest および Testing Library です。カバーするフローを要求すると、Scenario: セマンティック用語で言うと、ナビゲート、クリック、フィル、アサート (名前によるボタン、ラベルによるフィールド) が書き込まれます。次の再設計で機能しなくなる脆弱なCSSパスではありません。
実際のブラウザで実行する
テストは、実際のアプリに対して実際のブラウザーで実行されます。つまり、実際のレンダリング、実際のサインイン、実際の行レベルのセキュリティです。重要なことは何も嘲笑されていません。利用権の変更により、あるユーザーが別のユーザーのデータを読み取れるようになった場合、アプリと同じようにテストは失敗します。
データベースをフォークする
Scenarioはデータにアクセスする前に、データベースの使い捨てフォークを取得します。同じスキーマ、同じルールで、危険にさらされる行はありません。作成、編集、削除は実際に実行され、フォークに到達します。ファイルとコマース状態も同じ方法で複製されます。ランが終了するとフォークは捨てられます。
出口をキャプチャする
メール、Webhook、および外部の呼び出しは、開始されるのではなくキャプチャされます。テストでは、ウェルカム メールが誰に、どのような内容で送信されたかを確認できますが、メールが建物から出ていくことはありません。ロジックが実行されている間、統合は静かなままです。
領収書
実行するたびに、アプリが実際に行ったこと、つまりどの行を書き込んだのか、どのメールを送信したのか、どの外部呼び出しを試みたのかが記録されます。それぞれの記録には、書き込みをブロックしたセキュリティルールに至るまで、承認、キャプチャ、または拒否のマークが付けられ、その理由が付け加えられます。赤や緑だけではなく、何が起こったのか、そしてなぜ起こったのか。
判決
結果はチェックごと、ファイルごとに返されます。つまり、失敗したアサーション、中断したステップが、実行のレシートとともに返されます。構造化された障害が重要です。これにより、コードを作成した同じループが間違いを見つけて修正し、再度実行できるようになります。
門
テスト結果ゲート公開。Scenarioに障害が発生すると、ユーザーに公開が届く前に公開が停止します。そのため、「構築したときは動作しました」が「今は動作します」になり、デモから記憶されるのではなく、変更のたびに検証されます。
テストシステムが知っている実行方法
内蔵されており、自動的に実行され、見たいときにいつでも読むことができます。
実際のテストスタック
本物の Vitest、Testing Library、および jest-dom がブラウザで実行されます。プロのチームが使用するものと同じツールなので、テストはベンダーの方言ではなく、テストのように読み取れます。
Scenarioテスト
セマンティックな用語で記述されたエンドツーエンドのフロー — 役割でボタンを見つけ、ラベルでフィールドを見つけて、ユーザーが行うのと同じ方法で実際のアプリを操作します。
使い捨てデータベース
すべてのScenarioは、実際のデータベースのフォークに対して実行されます。書き込みは受け入れられ、アサートされ、破棄されます。データが実験に含まれることはありません。
何も漏れない
テスト実行では、メール、Webhook、およびコネクタ呼び出しを送信する代わりにキャプチャします。これらが発生しなくても、それらが発生したことを証明できます。
すべてのランニングにレシートが付いています
テストによって引き起こされたすべての副作用、つまり受け入れられたか、捕捉されたか、または拒否されたかをその理由とともに記録する台帳。信号機だけではない痕跡。
歴史と門
実行は長期にわたって追跡され、テストに合格すると公開が開始されます。検証はアプリの継続的な状態であり、1回限りのイベントではありません。
よくある質問
誰がテストを書きますか？
AIは、ビルド時に、デフォルトで標準スタック内で単体テストを実行します。カバーするフローを要求すると、そのフローに対してScenarioが書き込まれます。すべてのテストはアプリ内で読み取り可能なコードです。どれでも検査できますし、検査する必要はありません。
テストは実際のデータに影響しますか？
いいえ。Scenarioはデータベースの使い捨てフォークに対して実行されます。書き込みはそこで受け入れられ、実行が終了するとフォークとともに破棄されます。ファイルとコマース状態は同じ方法で複製されるため、すべてを削除するテストでも何も削除されません。
テストでは実際のメールが送信されますか、それとも統合に影響しますか？
いいえ — 送信トラフィックは送信されずにキャプチャされます。実行により、メールが誰に、何を使って送信されたかが記録され、テストでそれをアサートできます。顧客や接続されているツールがテストを見ることはありません。
テストが失敗した場合には何が表示されますか？
チェックごとの結果 (失敗したファイル、チェック、アサーション) に加え、実行で受け取った副作用と、それぞれが許可または拒否された理由。この構造により、AIはスクリーンショットから推測するのではなく、自身の間違いを診断して修正できるようになります。
テストではセキュリティルールが適用されますか？
はい — Scenarioは、模擬セッションではなく、実際の行レベルのルールに対する実際のサインインで実行されます。変更により、ユーザーが自分のものではないデータを表示できるようになった場合、ユーザーが表示する前にテストは失敗します。
テストに失敗すると公開がブ閉じられる可能性がありますか？
はい。 Scenarioはゲート公開を評決します。赤色のランは再び緑色になるまで公開を停止します。ゲートは、最後の変更が安全であることを期待するか、それがチェックされたと知るかの違いです。
アプリについて説明します。それを証明してもらいましょう。
組み込みとは、一緒に構築されることを意味します。テストはユーザーに表示されるのと同じアプリに対して実行されます。したがって、チェックアウト テストの失敗は、チェックアウトの失敗であり、モックではありません。
