vibe testing が実際になくすもの
なくなるのは「翻訳」の工程です。通常は、求める振る舞いはすでに分かっているのに、そこからセレクタや待機処理、アサーションへ変換するために1時間を費やします。その大半は、プロダクトそのものではなくフレームワークに関する作業です。振る舞いを記述して変換をエージェントに任せれば、意味を担う部分だけが残り、そうでない部分は消えます。
2つ目になくなるのは、保守のコストです。意図として表現されたステップは、ハードコードされたセレクタが壊れるようなデザイン変更にも耐えます。ボタンの位置が変わっても、意図そのものは成り立ったままだからです。
記述したチェックがうまくいかないパターン
曖昧すぎて失敗しようがない
「ダッシュボードが動作することを確認する」は失敗しようがありません。具体的な主張が何もないからです。
観測できる対象を挙げます。どの数値か、どの行か、どの状態か。
操作をアサーションにしている
「保存をクリックする」はステップであって、チェックではありません。実行はできても、何も証明しません。
その後に何が成り立っているべきかを書き、再読み込みしても確かめられる内容にします。
主体が曖昧
「ユーザーが自分の注文を見られる」では、どのユーザーなのかが定まりません。権限のバグはまさにそこに潜んでいます。
誰の注文なのかを明示し、他の人からは見えないことも確認します。
本物のチェックと飾りのチェックを分ける、たった一つの習慣
対象をわざと壊し、チェックが赤くなることを確認してください。1分もかかりませんが、そのチェックが何かに繋がっている唯一の証拠になります。
これは手書きのテスト以上に重要です。記述されたチェックには、都合よく解釈される余地が多く残るからです。アサーションに到達しないまま完了した実行は、成功ではありません。そうしたチェックを抱えていると気づく方法は、実際に失敗させてみることだけです。
はじめかた
セットアップでは、この機能をコーディングエージェントに組み込みます。これにより、コードを書いているその場でチェックを記述し、実行できます。
ここまでにターミナルは必要ありません。TestSprite のダッシュボードでプロジェクトを作成し、チェックを平易な言葉で記述して、対象のアプリを指定するだけです。チームの開発者がコマンドラインでの操作を好む場合は、同じことをこちらから実行できます： CLI リポジトリ。
最初に記述すべきもの
デモで見せるフロー。 壊れれば人前で発覚するため、最初にカバーすべき対象です。
お金や権限が関わるもの。 間違ったときの代償が最も大きく、どちらも静かに壊れます。
直近で壊れたもの。 一度でも足をすくわれたものは、恒久的なチェックを置く価値があります。しかも、どう記述すればよいかはすでに正確に分かっているはずです。
持ちこたえるチェックを記述する
自分を守ってくれるチェックと、パイプラインを飾るだけのチェックの違いは、ほぼ常に記述の仕方にあります。そして、その型は学べるものです。
良い記述には3つの要素があります。開始時の状態、操作、そしてその後に観測でき、再読み込みしても確かめられるものです。「保存済みフィルターがないログイン状態のユーザーとして、Recent という名前のフィルターを作成し、再読み込みして、サイドバーに表示されることを確認する」。どの要素も失敗し得るため、失敗すればどこで問題が起きたのかが分かります。
これを「フィルターが動作することを確認する」と比べてみてください。意図は同じですが、開始状態も、具体的な操作も、観測できるものもありません。これを満たすよう求められたエージェントは、それらしいことをして成功と報告し、あなたには何も分からないままです。最初の書き方に費やす15秒の差が、すべてを分けます。
そのうえで、実行するかどうかを毎回判断するのをやめる
記述したものであれコードであれ、人の判断を待つチェックは、忙しい週には飛ばされるチェックです。
ダッシュボードからリポジトリを接続すれば、すでに行っているデプロイを起点に実行が始まります。あるいは、自前のワークフローにステップを追加する方法もあります。
TestSprite は記述されたチェックをどう扱うのか
何が成り立っているべきかを伝えると、TestSprite がその確認方法を組み立て、デプロイ済みのアプリに対して実行します。本来の目的ではなかった翻訳の工程は、消えてなくなります。
結果が長持ちする理由は2つあります。ステップは DOM をたどる経路ではなく意図として保存されるため、ボタンの位置が変わるデザイン変更でもチェックは壊れません。もう一つは、何を試みたか、何が起きたか、どこで食い違ったかを記述した形で結果が返ってくることです。これにより、人がまず解釈しなくても、コーディングエージェントが失敗に対処できます。
改良も平易な言葉のまま行えます。チェックが緩すぎるなら、コードを編集するのではなく一文でそう伝えるだけです。記述によるチェックに価値があるのは、まさにこの点にあります。
vibe testing は実プロダクトで使えるほど信頼できますか？
フローの振る舞いをカバーする用途であれば、答えはイエスです。ただし、各チェックが具体的な対象を指定しており、失敗し得ることを確認済みであることが条件です。厳密な順序やコンポーネント単位のアサーションには、書かれたテストのほうが依然として適した道具です。
クリック操作を記録する方式と何が違うのですか？
記録は経路を捉えるため、経路が変われば壊れます。記述されたチェックは意図を捉えるため、変更されても生き残ります。保守の手間の差は、ほとんどがこの違いによるものです。
エージェントが記述を別の意味に解釈したらどうなりますか？
チェックを信頼する前に、生成されたステップに一度目を通してください。解釈の誤りはそこでは一目で分かりますが、成功した結果の中から後で見つけ出すのははるかに困難です。
チェックを書き直さずに調整できますか？
できます。最初に記述したときと同じように、平易な言葉で調整してください。
これはユニットテストの代わりになりますか？
なりません。ユニットテストのほうが高速で、ロジックの検証にも向いています。ここでカバーするのは、ユニットテストからは見えない層、つまり組み上がったプロダクトが正しく動作しているかどうかです。