Vize
テストとエージェント
エージェントによるコーディングは、テストの役割を変えます。
人が小さなパッチを書くとき、テストは、そのパッチが何かを壊していないかを教えてくれます。
エージェントがコードの大きな部分を書き換えられるようになると、テストは、「よい」とは何かをエージェントに伝えるための言葉にもなります。
そのため、テストの重要性は下がるどころか、上がります。
テストはプロジェクトの記憶
エージェントは局所的な推論が得意です。しかしプロジェクトは、いま与えられているプロンプトよりもずっと大きなものです。
ツールチェーンには、積み重ねてきた判断があります。
- 診断が何を伝えるべきか
- ソース上の範囲がどこを指すべきか
- 生成されるコードがどういう形であるべきか
- Vue のどのエッジケースに対応しているか
- どの実プロジェクトがコンパイルできる状態でなければならないか
- どの偽陽性が許容できないか
テストは、こうした判断を保存します。
テストがなければ、エージェントは変更のたびに、プロジェクトをゼロから理解し直すことになります。テストがあれば、プロジェクトの側から押し返せます。この動作は重要だ、この出力は意図したものだ、このエラーメッセージは利用者の体験の一部だ、と伝えられます。
スナップショットテストはとくに役に立つ
Vize は多くのスナップショットを使っています。ツールチェーンは、人が確認する必要のある構造化された出力を生成するからです。
- コンパイラの出力
- フォーマッタの出力
- リンターの診断
- 仮想 TypeScript
- ソースに対応付けた診断の位置
- 生成される Musea のメタデータ
- フィクスチャのプロジェクトから作られるビルド成果物
スナップショットは、アサーションの代わりにはなりません。広い範囲の動作をレビューできるようにするための手段です。
これは、エージェントによるコーディングにとって重要です。エージェントは大きな差分を短時間で作れるからです。よいスナップショットがそろっていれば、その差分を、人がレビューできる形で見られます。「コンパイラのどこかで何かが変わった」が、「このケースで、このレンダリング出力が変わった」になります。
レビューの対象として、はるかに扱いやすくなります。
決定性は契約
エージェントを使ったワークフローには、決定論的なツールが必要です。
テストが不安定だと、エージェントは自分のパッチが役に立ったのかを判断できません。実行するたびに出力の順序が変わると、スナップショットはノイズになります。診断がそのマシンの状態に左右されるなら、CI はくじ引きになります。
そのため Vize は、地味な細部を大切にしています。
- 出力の順序が安定していること
- 診断の ID が安定していること
- ソース上の範囲が安定していること
- 生成されるコードの形が安定していること
- フィクスチャのセットアップが安定していること
- 作業用のディレクトリが分離されていること
決定性は、CI のためだけのものではありません。人とエージェントが同じフィードバックループを共有できるようにするものです。
実プロジェクトのフィクスチャが、システムを誠実に保つ
ユニットテストは必要です。しかし、Vue のツールが実際に使われるのは、実際のプロジェクトの中です。
実際のプロジェクトには、次のようなものがあります。
- 変わったインポートのグラフ
- パッケージマネージャーごとのディレクトリ構成
- 生成されたファイル
- マクロの規約
- スタイルのプリプロセッサ
- 巨大なコンポーネントツリー
- 新しい書き方の隣に残っている古い書き方
だからこそ Vize は、実プロジェクトのフィクスチャとスナップショットに対するテストを続けています。目的は、本番で使えると早々に宣言することではありません。完璧なサンプルアプリの外でしか現れない、見落としやすい問題をすべて見つけることです。
こうした徹底的なチェックは、作り上げるのに時間がかかります。しかし、これが実験から本物のツールへ進む道です。
テストはコミュニティとの対話
コミュニティからのフィードバックは、トラッカーのコメントだけではありません。
次のようなものも含まれます。
- コンパイルに失敗する実際のプロジェクト
- 間違った範囲を指す診断
- 導入の妨げになる偽陽性
- 誰も予想していなかったリポジトリで起きる、急激な性能の低下
- ツールチェーンが理解できなかった、本番で使われている書き方
こうした報告は、ひとつ残らず、フィクスチャ、回帰テスト、ベンチマークのいずれかにするべきです。
そうすることで、フィードバックは記憶になります。実験的なツールは、そうやって時間をかけて本格的なものになっていきます。
エージェントには、小さくてよいループが必要
エージェントにとって最悪のテスト環境は、遅くて巨大なコマンドがひとつだけあり、最後にわかりにくいメッセージで失敗するものです。
最良の環境は、段階的なフィードバックを返します。
- 局所的な不変条件のための、速いユニットテスト
- 出力をレビューするための、スナップショットテスト
- フレームワークの動作のための、フィクスチャのテスト
- ツールの境界のための、的を絞った統合テスト
- プラットフォームと本番ビルドのための、CI のマトリックス
エージェントは、この段階に沿って検証を進められます。人も同じです。
Vize がテスト用のツールとスクリプトの整理に投資し続けている理由のひとつが、これです。よいプロジェクトは、適切なチェックを、実行しやすく、理解しやすく、リスクが高まったときには規模を広げやすいものにするべきです。
信頼は、繰り返し勝ち取るもの
README に「速い」や「正しい」と書いてあるからといって、ツールチェーンが信頼できるものになるわけではありません。
信頼は、次のようなことが起きるたびに積み重なります。
- 診断が正確である
- 修正が周囲のコードを壊さない
- スナップショットの変更を説明できる
- 実プロジェクトが通り続ける
- リリースの前に、CI が問題を捕まえる
- エージェントが、流れを見失わずに繰り返し作業できる
だから、Vize にとってテストは寄り道ではありません。
製品の一部です。
AI の時代に最もよいツールになるのは、最も多くのコードを生成するツールではないでしょう。コードを生成し、検証し、説明し、ときには却下することを、短い決定論的なループで行えるツールです。
そのループが現実のものになる場所が、テストです。