Selenium 4 の新しい秘訣
カテゴリ
サイモン・スチュワートは、シリーズの3回目の投稿で、Selenium 4 の新機能について引き続き語り、新しいリリースにおけるいくつかの秘訣をレビューします。
前回の投稿では、Selenium に貢献する方法と、バージョン番号を 4 に上げる理由についてお話しました。前置きはこれくらいにして、今日は、Selenium 4 が提供する新しい秘訣と機能の詳細について説明します。
要素の検索と相対ロケーター
ご存知のとおり、ページ上の要素を見つけるのは非常に難しい場合があります。非常に複雑な XPATH 式を使用したり、複雑な CSS セレクターなどを理解しようとしたりする人をたくさん見てきました。SeleniumConf では、この主題に関する講演全体が行われています。これを行うためのより良い方法がきっとあるはずです。
ページ上の要素の位置をどのように説明するか考えてみてください。電話でこれをどのように行うか考えてみてください。生の DOM について話すことは決してありません。「ああ、'foo' という 'id' を持つ SPAN の内側に入れ子になった 5 番目の DIV 要素を見つけてください。」そんなことは絶対に言いません！代わりに、ページ上のものの位置について話す場合、「あの画像の上のもの、そしてあのリンクの右にあるものを見つけてください」のように言うでしょう。
昔、Sahi というプロジェクトが、このように要素を特定し始めました。Sahi には リレーション API があり、これは要素を見つけるのに最適な方法であり、非常に流暢で快適に使用できました。私が数年前に WebDriver を始めたとき、ナラヤン (Sahi の作成者) と話していて、私は彼に、Sahi のこの主要な機能を実装するのを控えることを約束しました。それは素晴らしいものでしたが、Sahi が正当に誇りに思っていたものでもありました。しかし、現在では Tyco のような、このスタイルの API を実装している他のツールもあるため、Selenium でも同じことを行う時期が来たようです。Selenium 4 では、これらを「相対ロケーター」と呼んでいます。最初の実装では「フレンドリーロケーター」と呼ばれていたため、そう呼ぶこともありますが、「相対」の方がそれらの動作方法をより適切に表しています。それらは、near (近い)、above (上)、below (下)、left of (左)、right of (右) の少数です。これらを使用すると、ページ上の要素の位置について人間が使う言葉で話すことができます。
将来を見据えて、クライアント側だけでなく、Selenium サーバー側でも、ユーザーが新しいタイプのロケーターを追加できるようにすることも計画しています。たとえば、JS UI フレームワークは移り変わりますが (jquery を使用していた人を覚えていますか？)、人々が好む現在のツール (React など) 用のカスタムロケーターを追加できるのは素晴らしいことです。
Web サイトへの認証
プロジェクトを開始して以来、人々が求めてきた機能の 1 つは、Web サイトへの認証機能です。以前は、ブラウザが適切に進むように URL を作成することでこれを行うことができましたが、これは中間者攻撃者に認証情報を漏洩し、サーバーログに残してしまうため、ブラウザは徐々にこの機能を削除してきました。人々がテストで頻繁に行う必要があることを知っているので、それは残念です。Selenium 4 では、これらのサイトに対して認証するために使用できるユーザー名とパスワードを登録するメカニズムが提供されるようになりました。
ネットワークトラフィックのインターセプト
Selenium テストの一般的な不満は、テストが遅く、不安定であることです。ブラウザへのバインディングは優れており、W3C WebDriver 仕様によって完全に記述されていますが、エンドツーエンドテストは、単純なユニットテストよりも不安定になる可能性が高いのは事実です。可動部品が多く、問題が発生する可能性も高いためです。
この問題を解決する方法の 1 つは、アプリケーションのバックエンドをスタブアウトし、テストでネットワークトラフィックをインターセプトして、事前に準備された応答を返すことです。mountebank などのツールを使用すると、API テストが簡単になります。Selenium にも同様のツールがあれば素晴らしいのではないでしょうか。
Selenium 4 では、NetworkInterceptor (Java バインディングでの名前) を使用して、これを行うメカニズムが提供されるようになりました。WebDriver インスタンスを渡すと、ブラウザが HTTP リクエストを作成しようとするたびに呼び出され、ほぼすべてのものを返すことができます。
Chrome デバッグプロトコル
前に述べたように、Selenium 4 の優れた点の 1 つは、安定した最新のユーザー向け API を確保するための取り組みです。これはどういう意味でしょうか？まず、長い間、ブラウザ自動化の分野に競争が戻ってきたことを認識する必要があります。特に Puppeteer と Cypress の形であり、一歩下がって、それらは何を提供しているのでしょうか？それらは Chrome DevTools Protocol (CDP)> を基盤として構築されており、これは Chromium ベースのブラウザ内でデバッガーを有効にするために開発されたプロトコルです。
CDP が設計された目的のために、これはおしゃべりなプロトコルであり、ブラウザをイントロスペクトできるユーザー向け API ではありません。さらに悪いことに、テストとブラウザの間にネットワークホップを導入すると、ネットワークレイテンシが増加するため、このおしゃべりなプロトコルはテストの速度低下につながります。これが、Puppeteer などのツールでローカルマシンで実行することを推奨する理由です。個々のテストの速度には最適ですが、Sauce Labs などのサービスを簡単に使用できないため、並列化が難しくなります。
さらに問題を複雑にしているのは、CDP がデバッグプロトコルとして設計されているため、バージョン間で予告なしに変更される可能性があることです。これが、Puppeteer と Cypress が特定のバージョンのブラウザに結び付けられている理由であり、それがテスト作成者としてのあなたにジレンマを引き起こします。ブラウザの複数のバージョンでどのようにテストしますか？異なるブラウザを取得するためにテスト API を更新すると、有効な API 呼び出しができなくなる可能性があります。そうしないと、潜在的に古いバージョンのブラウザに縛られます。
それにもかかわらず、CDP を使用すると多くの可能性が開かれ、それが Selenium 4 に CDP のサポートを追加した理由です。実際、当社の新機能の一部は CDP の上に構築されています (ただし、詳細は非公開です!)
しかし、基本的なサポートを追加するだけではありません。Selenium 4 は、複数のバージョンの CDP を同時にサポートできます。つまり、テストを書き直すことなく、Chromium ベースのブラウザの最新バージョンとベータバージョンの両方でテストできます。これは、「理想化された CDP」を提供することで実現しています。これは安定しており、テストに必要な機能が網羅されています。その理想化された世界観が十分でない場合は、生の CDP API も公開し、テストに最適なものを柔軟に選択できるようにしています。
この経験を新しい W3C WebDriver Bidi 仕様にフィードバックしており、これによりテスターにとってより適切なものにするのに役立っています。
Selenium 4 のもう 1 つの重要な秘訣である新しい Selenium Grid に関連する詳細は、この投稿では省略します。次の投稿にご期待ください！
これは元々 https://saucelabs.com/blog/new-tricks-in-selenium-4 に投稿されました
