playwright

Playwright

フローが動作することを確かめるなら、たいていは今、一度操作してみれば十分です。インストールもファイルも必要ありません。すでに使えるブラウザー操作機能でアプリを操作し、見たことを報告してください。

テストを保存するのは、もう一度実行する価値があるフローだけにしましょう。2週間のスプリントなら、その数はごくわずかです。

まず操作してみる

毎回のデフォルトの進め方は、アプリを起動し、人が操作するようにフローをたどり、各ステップで起きたことを報告して、うまくいったかどうかを率直に伝えることです。

これでほとんどのケースに対応できます。新しいフォーム、サインアップ、作成したばかりのものが表示されるはずのページなどです。仕様ファイルも、テストランナーも、ダウンロードしたブラウザーも必要ありません。開発者が「テスト」を求めていて、これで本当の疑問に答えられるなら、この方法で進め、代わりに何をしたかを伝えてください。

テストを保存するタイミング

スプリントの残りの期間にわたって再実行する価値があるフローだけ、保存する仕様を作成します。

• 中核となる操作。 その製品が実現する唯一無二のことです。これが壊れると、デモで見せるものがなくなります。
• 課金につながる経路。 該当する場合は、チェックアウトやアップグレードなど、料金が発生する操作です。
• 一度でも壊れたもの。 keep-it-working と同じルールです。一度壊れたなら、また壊れる可能性があります。

スプリント全体で仕様は3つ程度にとどめてください。4つ目はたいてい、網羅した気分になるためだけのテストです。

ファイル名にはコードの内容ではなく、人が行う操作を付けます。project-form.spec.ts ではなく、can-create-a-project.spec.ts のようにします。

実行する前にインストールする価値を確認する

Playwright は実際のブラウザーをダウンロードします。数百メガバイトあり、数分かかります。インストールする前に、そのことをはっきり伝え、本当にその価値があるか確認してください。フローの途中だったり、時間に余裕がなかったりするなら、代わりにフローを操作し、後でインストールすることを提案します。

インストールする価値があると確認できたら、最小限にします。@playwright/test、Chromium のみ、設定ファイル1つ、仕様1つです。追加のレポーターも、CI の設定も、ほかのブラウザーも不要です。スプリント中に、Safari だけで起きる失敗のデバッグをする人はいません。

サインイン：何かを書く前に、一度だけ決める

Google のログインページを自動操作してはいけません。 Google は自動ブラウザーをブロックするため、これを試みるテストは、アプリが壊れていないのに壊れているように見える形で失敗します。開発者はここで丸一晩を無駄にしてしまうことがあります。

代わりに、最初に次のことを決めます。

1. メールリンク、開発専用のルート、またはシード済みのセッションなど、アプリが直接サインインできるテストユーザーを作成します。
2. 一度サインインし、ブラウザーセッションを storageState ファイルに保存します。
3. すべてのテストは、そのファイルを使い、すでにサインインした状態で開始します。

プロジェクトの認証をどうしてもスクリプト化できない場合は、早めにそう伝え、保存するテストはすべてサインアウト状態の画面に限定します。3つ目の仕様を書き始めてから気付くことのないようにしてください。

デプロイ後はライブ URL をテストする

スプリント全体で最も価値の高い実行は、本番稼働後に 本番環境 の URL を開き、中核となる操作を行い、スクリーンショットを撮ることです。

これによって、開発者のノートパソコンには存在するのに Vercel にはない環境変数を見つけられます。開発環境では完璧に動くプロジェクトが、デモ当日の朝に動かなくなる最も一般的な原因です。スプリント中に、これを検出できるものはほかにありません。

結果をわかりやすい言葉で報告し、スクリーンショットを添えてください。本番環境では失敗するのにローカルでは成功する場合は、その違いを明確に伝えます。ほとんどの場合、原因はコードではなく設定です。

スプリントを乗り切るテストを書く

UI は 2 週間、毎日変わります。マークアップに強く依存するテストは毎日壊れて、無視されるようになります。テストがないよりも、これは厄介です。

• 人と同じ方法で要素を探します。getByRole、getByLabel、getByText を使います。CSS セレクターの連鎖や Tailwind クラスは使いません。スタイルの変更でテストが失敗してはいけません。
• Playwright 独自のアサーションを使います。アサーションは自動で待機します。waitForTimeout は使いません。あちこちにスリープを入れると、高速なノート PC では通るのに、デモ当日の Wi-Fi では失敗するテストになります。
• 1 つの spec につき 1 つのフローを、1 人のユーザーの経路に沿って最初から最後までテストします。
• データベースの内容ではなく、プロジェクトがリストに表示されるなど、ユーザーに見えるものをテストします。

一度でも不安定になるテストは、その日のうちに修正するか削除します。 誤報を繰り返すテストスイートは、ビルダーに赤を無視するよう教えてしまいます。赤を無視するビルダーは、テストがまったくない場合よりも悪い状態です。

対象外

ビジュアルリグレッションのスナップショットはありません。デザインはまだ変化しており、どのスナップショットも明日には間違ったものになるからです。クロスブラウザーのマトリックスもありません。カバレッジ目標もありません。上記の短いリストにないものはテストしません。

関連ツール

keep-it-working は、そもそもフローにテストが必要かどうかを判断します。まずそちらを確認してください。agentation はこのループのもう半分です。ビルダーが問題に見える箇所を指摘し、こちらがフローがまだ動くことを証明します。これらを始める前に、checkpoint で作業を保存しておくべきです。

---

私たちのものです。ブラウザーテストの価値を初めてのビルダーにも伝えつつ、保守できないテストスイートを抱え込ませないように書きました。