正直な出発点
コードが読めないのであれば、コードをレビューすることはできません。そのことに引け目を感じる必要はありません。代わりになるのはレビューではなく、動作を確認することです。どのみちユーザーが行うのはそれであり、読むだけでは見逃してしまう種類の問題を捉えられます。
Lovableのコードのバグが潜んでいる場所
生成されたアプリは、予測できる順序で壊れます。まずは次の点を確認してください。
| 保存されたように見えて、保存されていない | フォームには成功メッセージが表示されるのに、再読み込みするとデータが消えています。保存を信じる前に、必ずページを再読み込みしてください。 |
| 空の状態とエラーの状態 | 正常系は作り込まれ、デモでも示されています。一方、結果が0件の場合やリクエストが失敗した場合は、作られていないことがよくあります。データがない状態で試し、わざと誤った入力でも試してください。 |
| 2人目のユーザー | アプリを作ったアカウントでは、すべてが動きます。ほかの人にとって最初に壊れるのは、権限、所有権、そして表示範囲です。誰かに見せる前に、2つ目のアカウントでサインインしてください。 |
効き続ける確認の仕組み
手作業での確認は、週末の趣味プロジェクトなら十分ですが、プロンプトを重ね始めた時点でスケールしなくなります。新しい指示のたびに、昨日まで動いていたものが気づかないうちに失われる可能性があり、しかも手作業の確認は回を重ねるごとに短くなっていきます。
望ましいのは、確認の内容がテストコードではなく普通の言葉で書き残され、自動的に実行されることです。セットアップによってその機能がエージェントの手に渡り、開発と並行して確認が行われるようになります。
これらはすべてTestSpriteのダッシュボードでも利用でき、普段ターミナルで作業しないのであれば、通常はそちらのほうが適しています。CLIの詳細は CLIリポジトリにあります。
初日から持っておく価値のある3つの確認
サインアップして、もう一度サインインします。 生成されたアプリが壊れる箇所としてはここが最も多く、しかも実際のユーザーが最初に行う操作です。
何かを作成し、再読み込みして、まだ残っていることを確認します。 この確認ひとつで、最もよくある、そして最もばつの悪い不具合を捉えられます。
まっさらな新規アカウントで、そのアプリの目的そのものである操作を行います。 それが見ず知らずの人にとっても動くなら、形になっています。
修正がきちんと当たるバグの伝え方
不具合があると、つい「壊れています」と言いたくなります。しかしそれではエージェントに伝わる情報がほとんどなく、返ってくるのは本来とは別の、近くにあるものを直した変更です。
3つの文にすると、はるかにうまくいきます。しかも、どれにも技術的な語彙は必要ありません。自分が行った操作を順番どおりに。期待していたこと。実際に起きたこと。「フォームに入力して保存を押しました。新しい項目がリストに表示されると思っていました。再読み込みするまでリストは空のままでした」——これは本当に優れたバグ報告であり、欠陥そのものを直接指し示します。
この3つの文は、そのまま残しておく確認項目にもなります。一度書き留めておけば、今後の変更のたびに再実行でき、それが同じ問題の再発を止める方法になります。
確認する順番
あてもなくクリックして回るより早く問題を見つけられる手順があり、所要時間は約10分です。
まずサインアウトした状態から始め、まっさらな新規ユーザーとしてサインアップします。この経路こそ、自分自身が最も使っていないからです。次に、そのアプリが存在する理由そのものである操作を最後まで通しで行い、結果を信じる前にページを再読み込みします。続いて、今度はわざと間違ったやり方で行います。必須項目を空のままにする、数値を入れる欄に文字を入れる、ばかげたものをアップロードする、といった具合です。最後に何かを削除し、隠れているだけでなく本当に消えていることを確認します。
この4つはそれぞれ1〜2分で終わり、いずれも生成されたアプリが壊れやすい領域に対応しています。この順番で行うことが重要です。サインアップが壊れていれば、それ以降はすべてテストできなくなり、誰もたどり着けない機能に1時間を費やすことが珍しくないからです。
共有する準備ができたら
アプリを実際の場に出す前に、思い出したときではなく変更のたびに確認が自動で実行されるようにしておきましょう。方法は次の2つです。
ダッシュボードからリポジトリを接続すれば、すでに作成しているデプロイを起点に実行が始まります。あるいは、自分のワークフローにステップを追加する方法もあります。
TestSpriteが確認を代行する仕組み
あるべき状態を普通の言葉で記述すれば、クリック操作はTestSpriteが行います。テストコードもフレームワークもターミナルも必要ありません。ダッシュボードでプロジェクトを作成し、対象のアプリを指定して、正しく動いている状態がどのようなものかを伝えるだけです。
このページで挙げた4つの領域が、そのままカバーする範囲です。新規アカウントでサインアップし、何かを作成して再読み込みし、保存されたことを確認します。無効な値を送信して、アプリがその旨を伝えるかを確かめます。そして同じ流れを2人目のユーザーとして実行し、自分のセッションに組み込まれた権限の前提をあぶり出します。
プロンプトを重ねていくうえで重要なのは、確認項目が残り続けることです。すべての変更は、それ以前に動いていたすべてに対して検証されます。これが、ひとつを直すと別のどこかが気づかないうちに壊れるという繰り返しを止めてくれます。
これを行うにはコードが書ける必要がありますか？
いいえ。確認内容は普通の言葉で記述され、人が実際に操作するのと同じように、アプリのインターフェースを通して実行されます。
自分では動くのに、ほかの人では動かないのはなぜですか？
たいていは権限かデータの所有権が原因です。アプリを作ったアカウントは、新規アカウントにはないデータとアクセス権を持っています。2人目のユーザーとしてテストすれば、これはすぐに表面化します。
テストは、さらにプロンプトを出す前と後のどちらで行うべきですか？
両方ですが、より重要なのは後のほうです。最新の指示より前から存在していた確認項目こそが、その指示が何かを壊したかどうかを教えてくれます。
修正するたびに別の箇所が壊れる場合はどうすればよいですか？
それは、最後にまとめてではなく継続的に確認を実行すべきというサインです。変更ごとに、それ以前に動いていたすべてに対して検証されます。
これはLovableだけのものですか？
いいえ。何によって生成されたものであれ、短時間で生成されたものには同じ不具合が現れます。Lovableのユーザーが早く直面するのは、それだけ早くリリースするからです。