AIはドロップダウンとモーダルをどのようにテストできるのか？
Zeshi 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を使って、ドロップダウンとモーダルのテストを始めましょう。