AIはどのようにしてドロップダウンとモーダルをテストできるのか？
Zheshi Du
ドロップダウンとモーダルは、自動テストが静かに諦めてしまう箇所です。
DOMで見つけにくいからではありません。ユーザーが何らかの操作を行った後にのみ意味のある状態で存在するため、正しくテストするのが難しいのです。配送オプションを含むドロップダウンは、誰かがクリックするまでそのオプションを表示しません。支払い確認を求めるモーダルは、誰かがチェックアウトフローの最後に到達するまで表示されません。親ドロップダウンの選択に基づいて内容が変わるネストされたドロップダウンは、両方のインタラクションが順番に行われない限り、意味のある状態を表示しません。
これらの要素を正しくテストするには、実際のユーザーが行うことをする必要があります。要素を開くアクションを実行し、内部のコンテンツを操作し、ソースコード上での要素の存在だけでなく、インタラクション全体に対してプロダクトが正しく反応することを検証するのです。
コードレイヤーのツールが動的要素に苦戦する理由
ドロップダウンとモーダルの課題は、それらを見つけることではありません。コードレイヤーのツールは、ソースツリー内のすべてのドロップダウンやモーダルコンポーネントを難なく見つけられます。
課題は、ソースでそれらを見つけても、それらが正しく動作するかどうかについて何も有用な情報が得られないことです。
ドロップダウンコンポーネントは、初期の閉じた状態でコード内に存在します。正しいオプションが表示されるかどうかをテストするには、まず開く必要があります。開くためには、開くきっかけとなるユーザーアクションをシミュレートする必要があります。オプションを選択することで正しい後続効果が生じるかどうかをテストするには、オプションを選択する必要があります。そのためには、ライブ環境でドロップダウンが開いた状態である必要があり、そのためにはトリガーアクションが先に実行されている必要があります。
モーダルも同じ構造です。コンポーネントはソースに存在します。意味のある状態は、実行中のアプリケーションでトリガー条件が満たされた後にのみ現れます。そして、モーダルのコンテンツとのインタラクション（フォームの入力、確認ボタンのクリック、モーダル内のリストからの選択）は、正しいユーザーフローを経てモーダルに到達したというコンテキストにおいてのみ意味を持ちます。
コードレイヤーのツールはコンポーネントの定義に対してアサートします。プロダクトレイヤーのテストは、コンポーネントを意味のある状態にするフローを実行し、その後それを操作します。
ドロップダウンとモーダルのテストが実際に必要とするもの
ドロップダウンとモーダルの効果的なテストには、ライブアプリケーションを操作する場合にのみ意味を成す4つの要素が必要です。
要素を開くこと。ドロップダウンのトリガーをクリックし、モーダルを表示させる条件に到達すること。テストは、有用な検証を行う前にまずそこに到達する必要があります。
コンテンツを観察すること。ドロップダウンはどんなオプションを提示しているか？モーダルには何が含まれているか？現在のアプリケーション状態において、含まれているべき内容になっているか？
選択またはアクションを実行すること。ドロップダウンからオプションを選択し、モーダル内のボタンをクリックし、モーダル内のフォームを送信すること。インタラクション自体が重要です。
後続の効果を検証すること。インタラクション後に何が起きたか？ドロップダウンの選択は、それが属するフォームを更新したか？モーダルの確認は期待された結果をトリガーしたか？モーダルを閉じることで状態が正しく保持または破棄されたか？
ほとんどのテストフレームワークが検証を試みるのは、4番目のステップだけです。最初の3つのステップは、実際にアプリケーションを実行してそれを操作することを必要とします。
TestSpriteがドロップダウンとモーダルをテストする方法
TestSpriteは、実際のユーザーが行うことをすることで、ドロップダウンとモーダルをテストします。開き、コンテンツを操作し、何が起こるかを観察します。
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
TestSpriteの並列探索エージェントは、実際のユーザーと同様にライブアプリケーションをナビゲートします。エージェントがドロップダウンに遭遇すると、それを開きます。ドロップダウンが提示するオプションを読み取ります。オプションを選択し、フォーム、ページ、またはフローがどのように反応するかを観察します。機能するはずのオプションを試し、プロダクトが選択を正しく処理するかどうかを確認します。
エージェントがモーダルのトリガーに遭遇すると、モーダルをトリガーします。モーダルのコンテンツを操作します。モーダルにフォームが含まれている場合、エージェントはそれを入力します。モーダルに確認プロンプトが含まれている場合、エージェントは確認します。モーダルを閉じることができる場合、エージェントはそれを閉じて、閉じた後の状態が正しいかどうかを確認します。
エージェントは、開発者がほとんどテストを書かないエッジケースも検証します。正しく開くのに Escape キーで閉じられないモーダル。正しい選択肢を表示するのに、オプションを選択しても依存フィールドが更新されないドロップダウン。親の選択が正しく伝播されないため、第2階層に誤った選択肢が表示されるネストされたドロップダウン。表示されるべきでないタイミングで表示される、あるいは表示されるべきタイミングで表示されない確認モーダル。
これらは特殊な障害モードではありません。AI コーディングセッションがステート管理をリファクタリングしたり、コンポーネントのロジックを再編成したりする際に壊れる、インタラクションの細部です。差分にドロップダウンやモーダルが含まれていないため、誰も確認しようとしないのです。
シナリオ：誤ったフィールドを更新したドロップダウン
開発者が Cursor を使ってプロジェクト設定フォームを構築します。このフォームにはプロジェクトカテゴリを選択するドロップダウンが含まれており、その下にある依存ドロップダウンで選択できるサブカテゴリの選択肢を更新する必要があります。AI コーディングセッションは、両方のドロップダウン、それらの依存ロジック、およびフォーム送信ハンドラーを実装します。
TestSprite の探索エージェントがプロジェクト設定フォームに移動し、操作します。
エージェントはカテゴリドロップダウンを開いてオプションを選択します。サブカテゴリドロップダウンが更新され、そのカテゴリに適した選択肢が表示されます。エージェントはサブカテゴリを選択してフォームを送信します。
フォームは正常に送信されます。エージェントはその後プロジェクト一覧に移動し、新しいプロジェクトが正しいカテゴリとサブカテゴリの値で表示されるかを確認します。
カテゴリは正しい。サブカテゴリは間違っている。プロジェクトは、エージェントが選択したサブカテゴリではなく、依存ドロップダウンの初期デフォルト状態のサブカテゴリで作成されていました。ドロップダウンには正しいサブカテゴリの選択肢が表示されていました。しかしフォームの送信では、選択された値が正しく取得されていませんでした。依存ロジックは表示を更新しましたが、フォーム送信が読み取る値は更新されていなかったのです。
コードレイヤーのテストは、カテゴリの選択が変更されたときにサブカテゴリドロップダウンが正しい選択肢を表示することを確認できます。しかし、両方のドロップダウンを開いて順番に選択を行い、フォームを送信した上で作成されたレコードを確認するエージェントだけが、この障害を検出できます。
障害の説明は Cursor セッションに返されます：送信されたフォーム、選択されたカテゴリとサブカテゴリ、および作成されたプロジェクトレコードに実際に表示されている内容。コーディングエージェントはフォーム送信ハンドラーを特定し、依存ドロップダウンの選択値ではなく初期値を読み取っていることを発見し、同じセッション内で修正を適用します。
マルチステップフローにおけるモーダル
フローの途中で表示されるモーダルは、文脈の中でのみ現れる障害が特に起きやすいです。
ユーザーがレコードを削除しようとしたときに表示される削除確認モーダル。ユーザーが未保存のフォームから離れようとしたときに表示される警告モーダル。ユーザーが制限された機能に初めてアクセスしようとしたときに表示される権限付与モーダル。
これらはそれぞれ、通常のプロダクトナビゲーションを通じてトリガー条件に到達する必要があります。TestSprite のエージェントは、直接 DOM を操作してモーダルを強制的に開くのではなく、そこへ至るプロダクトフローをナビゲートすることでそれらの条件に到達します。
エージェントが確認モーダルに到達すると、確認操作を行います。そして確認によって期待通りの結果が生まれたかを観察します。警告モーダルに到達した場合は、警告を無視して続行するパスとキャンセルするパスの両方をテストします。それぞれのケースで状態が正しく保持または破棄されているかを観察します。
Auto-Heal Rerun は、AI コーディングのリファクタリング後にモーダルの動作が構造的な理由（動作上の理由ではなく）で変化したケースに対応します。あるインタラクションでトリガーされていたモーダルが、わずかに異なるインタラクションでトリガーされるようになった場合でも、テストは適応します。一方、本当の動作リグレッション——モーダルが正しく確認されなくなった、または正しく閉じられなくなった——は明確に表面化します。
まとめ
AI はドロップダウンとモーダルをテストできます。ただし、それらを開き、コンテンツを操作し、下流への影響を観察できるように構築されている場合に限ります。それにはコードレイヤーではなく、プロダクトレイヤーで動作することが必要です。
TestSprite の探索エージェントはライブアプリケーションをナビゲートし、実際のユーザーと同じようにドロップダウンやモーダルを操作します。ドロップダウンを開き、選択を行い、プロダクトが正しく反応するかを確認します。通常のフローナビゲーションを通じてモーダルのトリガーに到達し、モーダルのコンテンツを操作し、その結果が期待と一致しているかを確認します。
エージェントが発見する障害は、ソースコードやコードレイヤーのテストでは見えません。それらは実際のユーザーフローの文脈の中でその要素が実際に使用されたときに現れます。これはまさに TestSprite のエージェントがテストを行う方法です。
今すぐ AI IDE 内から TestSprite でドロップダウンとモーダルのテストを始めましょう。