TestSprite Auto-Authはテスト実行中のログインフローをどのように処理するか
Rui Li
認証は、自動テストが伝統的に機能しなくなる場所です。
このパターンは普遍的です。チームがテストカバレッジを構築し、デモではすべてが機能します。しかしその後、セッショントークンの期限切れ、OAuthリフレッシュの未処理、またはログインフローのわずかな変更によってハードコードされた認証スクリプトが壊れ、午前3時にスイートが失敗し始めます。失敗するテストは何もテストしていません。玄関口で止まっているだけです。そして最も重要なフロー、ユーザーが実際に利用する認証済みのフローこそが、まさにその扉の向こう側にあります。
Auto-AuthはTestSpriteの解答です。すべてのテスト実行前に認証を自動的に処理し、一度設定するだけで、エージェントはログイン画面と格闘するのではなくプロダクトのテストに集中できます。
ログインが自動テストにとって典型的なボトルネックとなる理由
認証済みテストには構造的な問題があります。認証情報とセッションはステートフルで有効期限があり、環境に依存しますが、テスト実行は繰り返し可能で無人であることが求められます。
今日キャプチャしたセッションは来週には無効です。午前の実行で機能したトークンは夕方の実行前に期限切れになります。OAuthフローにはリフレッシュサイクルが必要ですが、静的なスクリプトはそれを実行しません。また、スケジュールされた実行（誰も監視せずに継続的なカバレッジを提供するはずのもの）は、プロダクトとは無関係な大量の失敗を生む、ただ1つの期限切れ認証情報によって止まってしまいます。
チームはこれをその場しのぎで対処しています。セキュリティチームが当然嫌がる長期テストトークン、認証ページが変わると壊れるログインスクリプト、あるいはスケジュールによる認証済みフローのテストを単純に行わないこと（これにより、プロダクトの大部分がリグレッションカバレッジから静かに除外されます）。
Auto-Authが代わりに行うこと
スタンダードプラン以上で利用可能なAuto-Authは、すべてのテスト実行前に自動的に認証を実行します。プロジェクトに対して一度設定するだけで、その後のすべての実行（IDEからのトリガー、スケジュール実行、CI上の実行）は、有効な認証済みセッションを自律的に確立することから始まります。
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
実際のプロダクトを使用するということは、ログインユーザーとして使用することを意味します。Auto-Authはその最初のステップを透過的にします。探索エージェントがナビゲーションを開始する時点で、エージェントはちょうどサインインした実際のユーザーと同様に、新鮮なセッションを持ってプロダクト内にいます。
トークンが古くなっても手動で再実行する必要はありません。カバレッジの途中でトークンが期限切れになることはなく、認証は毎回、各実行の開始時に再確立されます。
サポートする3つのメカニズム
Auto-Authは、実際のプロダクトの大部分を占める3つの認証パターンをカバーしています。
パスワードエンドポイント。最もシンプルなケースです。実行は設定済みのテスト認証情報を使用してログインエンドポイントに対して認証を行い、その結果のセッションをテスト全体に引き継ぎます。プロダクトのセッションが通常のスケジュールで期限切れになっても問題ありません。次の実行で新たに認証を行うためです。
OAuthリフレッシュトークン。OAuth認証を使用するプロダクトの場合、Auto-Authはリフレッシュトークンと有効なアクセストークンを交換するリフレッシュフローを実行の開始前に実行します。静的スクリプトがスキップするリフレッシュサイクルはセットアップの一部として処理されるため、数週間間隔があくスケジュール実行でも、それぞれが有効なトークンで開始されます。
AWS Cognito。Cognitoで構築されたプロダクトは、チームがCognitoの仕様に合わせたスクリプトを作成することなく、Cognitoの認証フローのファーストクラスサポートを受けられます。
いずれの場合も、設定はプロジェクトレベルで管理されます。Webポータルで一度設定するだけで、テストをトリガーするすべてのインターフェース（CursorまたはClaude Code内からのMCP、スケジュール済みリグレッション、プルリクエスト上のGitHub Actions）が動作する認証を継承します。
解放されるもの：ログインの先にあるカバレッジ
実質的な価値はログイン自体にあるのではありません。ログインがブロックしていたすべてのフローにあります。
スケジュール済みリグレッションが信頼できるものになります。ステージング環境への夜間実行は、認証済みプロダクトの表面（ダッシュボード、設定、請求、チーム管理）をカバーします。金曜夜のトークン期限切れによって月曜朝に偽の失敗が大量発生することはありません。「前回との変更点」のレビューは、プロダクトに関するものだけになります。
CIカバレッジがマーケティングページを超えて広がります。プルリクエストのTestSprite実行はプレビューデプロイメントのログイン済みエクスペリエンスをナビゲートします。これはAIコーディングセッションによるリグレッションが実際に存在する場所です。Claude Codeのセッションでログインページが壊れることはほとんどありません。しかし、その3画面先の何かが壊れることは多くあります。
そして、ロールベースのフローが体系的にテスト可能になります。パーミッションモデルを持つプロダクトは、異なるユーザータイプとしてのカバレッジが必要であり、設定済みアカウントごとの認証済みセッションが、エージェントがViewerには見えるべきものが見えているか、Adminが実行できるべきことができるかを検証するための前提条件となります。
シナリオ：誤検知を出さなくなった夜間実行
5人チームがAWS Cognito上でプロパティ管理SaaSを構築しています。家主はログインして物件、リース、修繕依頼を管理します。TestSprite以前、スケジュールテストの試みには繰り返す失敗パターンがありました。認証ヘルパースクリプトがトークン処理やCognito設定が変わるたびに月に1回ほど壊れ、そのたびにスイート全体を赤に染めていました。3回目の誤検知の後、チームは夜間のメールを無視し始めました。それは本当に重大な問題があった朝も同様でした。
チームはStandardプランでTestSpriteに移行し、Cognitoの設定とロールスコープ付きテストアカウントのセットでプロジェクトのAuto-Authを設定し、ステージングへの夜間スケジュールを設定しました。
その後数週間は、良い意味で静かでした。毎晩、実行はCognito経由で新たに認証を行い、エージェントは認証済みプロダクトを操作しました。リースの作成、修繕依頼のログ記録、家主ダッシュボードの確認などです。
そして木曜夜の実行で1件の変更が検出されました。その日のClaude Codeセッションが修繕依頼フローを刷新していましたが、実行によってテナントロールのアカウントが修繕費用の見積もり（常に家主専用だったデータ）を閲覧できるようになっていることが判明しました。リワークによって共有ビューにリクエストオブジェクト全体がフェッチされるようになっていたためです。検出結果は具体的でした。どのロール、どの画面、何が表示されていたか、何が表示されるべきでなかったかが記載されていました。
失敗メールのインライン分析にはまさにその内容が記載されていました。金曜の朝、修正には20分かかりました。数週間誰も認証に触れておらず、その必要もありませんでした。夜間ログインが毎晩機能していたからこそ、重要な夜に検出された問題がプロダクトに関するものだったのです。
まとめ
Auto-Authはログインフローを繰り返す失敗の原因ではなく、解決済みのセットアップステップにすることで処理します。認証はすべての実行前に自動的に実行され、パスワードエンドポイント、OAuthリフレッシュトークン、AWS Cognitoをサポートし、プロジェクトごとに一度設定するだけですべてのテスト表面に継承されます。
実際に提供されるのは、ログイン後のカバレッジです。ユーザーが時間を費やす認証済みフロー、そしてAIコーディングセッションがリグレッションをもたらす場所を、クレデンシャルの煩わしさや深夜の誤アラームなしに、スケジュールおよびCI上でテストします。
TestSprite StandardでAuto-Authをセットアップして、今すぐ認証済みフローを継続的なカバレッジのもとに置きましょう。