物事がどのようにしてそうなったのかについての考察

プロジェクトの特定の部分がどのように、そしてなぜ作成されたのかについて、主に Selenium 開発者にとって興味深い詳細

このドキュメントは以前は wiki にありました

はじめに

これは作業中です。ご存知のことや覚えてることなど、お気軽に追加してください。

Automation Atoms はどのようにして生まれたのか？

2012-04-04 に、jimevans が #selenium IRC チャンネルで尋ねました

「お尋ねしたいのは、Automation Atoms の歴史についてです。それらがゼウスの頭から完全に形成されたかのように突然現れたのを覚えているようですが、そうではなかったはずです。その概念がどのようにして生まれたのか、記憶を新たにしてくれませんか？」

すると simonstewart が私たちに素敵な短い物語を語り始めました

もちろんです。楽に座っていますか？では、始めましょう。（イギリスのジョークですよ）

画面が溶けて波線が想像され、Selenium と WebDriver が別々のプロジェクトだった時代にタイムスリップします。プロジェクトが統合される前は、WebDriver に非常に多くの重複するコードがありました。重複していましたが、共有されていませんでした。Firefox ドライバーは JS で書かれていました。IE ドライバーは主に C++ でした。Chrome ドライバーは主に JS でしたが、Firefox ドライバーとは異なる JS でした。そして、HtmlUnit は独自のものでした。

その後、Selenium Core を追加しました。さらに多くの JS が基本的に同じことをしていました。

Google 内で、私はブラウザ自動化チームの TL になっていました。そして、私たち自身のフレームワークをまとめようとしていました。それは JS で書かれており、かつては Core をベースにしていましたが、独自の道に進む前に分岐しました。

つまり、複数のコードベース、多かれ少なかれ同じことをする多くの JS。そして、たくさんのバグ。エッジケースでの奇妙な動作の不一致。

*身震い*

そこで、私は少し考えました。（危険なのは承知しています）そのアイデアは、3 つのフレームワーク（Core、WebDriver、Google ツール）すべてから「最高の」コードを抽出することでした。それらを共有できるコードに分解します。「ブラウザ自動化の最小の不可分な単位」。

または略して「atoms（原子）」。

これらは*すべて*の基礎として使用できます。ブラウザ間および API 間で一貫した動作。もう 1 つの重要な点は、WebDriver と Core の JS コードは有機的に成長したということです。これは、「二度と編集したくない」というのを丁寧な言い方にしたものです。これは、品質が疑わしいものを丁寧な言い方にしたものです。場所によっては。

したがって、高品質が重要でした。そして、コードをモジュールに分割したかったのです。なぜなら、10k LOC のファイルを編集するのは賢明な考えではないからです。

Google 内には Closure と呼ばれるライブラリがありました。これは、モジュール化だけでなく、コンパイルによってモジュールを単一のファイルに「非正規化」することもできました。そして、それがオープンソース化されることを知っていました。そこで、Google のコードベースでライブラリの構築を開始しました。（リリースされていないライブラリ、コードレビューツール、および驚くべきテストインフラストラクチャにアクセスできる場所で）。Closure Library を使用して。

「dom.js」はおそらく私が最初に書いたファイルです。（確認できます）。Greg Dennis と Jason Leyba が楽しみに参加しました。そして、atoms はそれ以来成長し続けています。

技術的には、「javascript/atoms」の外にあるものはすべて molecules（分子）と呼ぶべきです。しかし、それでは atomic drivers（原子ドライバー）があるとは言えません。そして、それらを説明するために 50 年代のイメージを使用することもできません。

*ため息*

jimevans が返信しました。「molecular drivers（分子ドライバー）？」

そして simonstewart はこう締めくくりました

確かに :) そのアイデアは、atoms が最下層であるということです。そして、atoms を構成して、「javascript/{selenium,webdriver}-atoms」で WebDriver または RC API に準拠させます。そして、必要に応じてそれらを取り込みます。

Crazy-Fun な物語

Simon Stewart

それでは、プロジェクトの非常に初期の頃に戻りましょう

私一人だった頃です
（WebDriver プロジェクトのことです。Selenium 自体ではありません）
私は複数の異なる言語をカバーしたいと思っていたので、それらすべてで動作するビルドツールが必要でした
つまり、他の言語での作業を苦痛にするような、1 つの言語を優先する組み込みの優先設定がないものです
ant は Java に偏っています。Maven も同様です。
nant と msbuild は .NET に偏っています
rake は、一方では、何も十分にサポートしていません
しかし、これが重要ですが、有効な rake スクリプトはすべて有効な Ruby プログラムでもあります
rake を拡張してあらゆるものをビルドすることが可能です
したがって、rake になりました
最初の rake ファイルは非常に小さく、管理しやすいものでした
しかし、プロジェクトが成長するにつれて、Rakefile も成長しました
それに対処できる人が一人（私）しかいなくなり、それでもかなり不安定でした
そこで、ビルドできないプロジェクトにするのではなく、いくつかのヘビーリフティングを行うヘルパーメソッドを抽出しました
これにより、Rakefile が再び理解できるようになりました
しかし、プロジェクトは成長し続けました。ますます大きくなりました
そして、Rakefile はますます理解するのが難しくなりました
当時、私は素晴らしいビルドシステムを持っている Google で働いていました
Google のシステムは宣言型であり、複数の異なる言語間で一貫して動作します
そして、最も重要なことは、ビルドを単一のファイルから小さな断片に分割することです
Google の OSS 担当者に、ビルド文法をオープンソース化しても大丈夫かどうか尋ねたところ、許可が下りました
そこで、そのビルド文法を Selenium コードベースにレイヤー化しました
1 つの小さな変更（ディクショナリ引数を処理します）を加えて
しかし、その文法は rake の上にあります
今でも、この時を過ぎても
そして問題があります
そして、それは rake がシングルスレッドであるということです
したがって、ビルドはシリアルに実行するように制約されています
「multitask」タイプを使用して改善することはできますが、それを試したところ、事態は非常に早く、非常に混乱しました
したがって、私たちの次のハードルは、crazyfun.rb が遅いことです。もっと速くする必要があります
それは crazyfun の書き換えを意味します
私は Java が一番得意です
そこで、Java と JS のコンパイルを処理する Java の新しいバージョンを試作しました
大幅に高速化されています
しかし、これも重要ですが、それは試作品です
そのコードは使い捨てになるように設計されました。
物事が証明されたので、本当にクリーンな実装を行いたいと思っています
しかし、私は迷っています
新しい、非常に高速な crazyfun Java を Ruby バージョンを置き換えるのに十分なほど「完成」させますか？

ドライバー実行ファイルに関する物語


jimevans
noob_einsteinsfo: よし、お話の時間だ。楽に座っているかな？では、始めよう。
noob_einsteinsfo: 私が初めてプロジェクトに取り組み始めた頃（2010 年頃）、すべてのブラウザのドライバーはプロジェクトによって構築および保守されていました。
当時、それは IE、Firefox、Chrome を意味していました。
これらのドライバーはすべて、Selenium Standalone Server の一部としてパッケージ化され、さまざまな言語バインディングにもパッケージ化されていました。
これは意識的な決定であり、ローカルで実行している場合は、特定のブラウザを自動化するためだけに Java ランタイムをマシンにインストールする必要がないようにするためでした。
ブラウザドライバーが別々の実行可能ファイルとして開発されるようになった要因が 2 つありました。
ちょっと脱線しますが、WebDriver の哲学は、特定のブラウザに「最適な」メカニズムを使用してブラウザを自動化することであることを覚えておいてください。
IE の場合、それは COM インターフェイスを使用することを意味します。当時の Firefox の場合、それはブラウザ拡張機能を使用することを意味しました。Chrome の場合も、ブラウザ拡張機能を意味しました。
つまり、IE ドライバーは、言語バインディングによってロードされ、言語によって提供されるネイティブコードメカニズム（Java の場合は JNI、.NET の場合は P/Invoke、Python の場合は ctypes など）を介して通信する C++ の DLL として開発されたことを意味します。
また、Firefox ドライバーは、さまざまな言語バインディング内にパッケージ化され、抽出され、Firefox のプロファイルで使用されるブラウザ拡張機能として開発されたことを意味しました。
前述のように、IE ドライバーは DLL として実装され、さまざまな言語バインディングに対して異なるメカニズムを使用してロードおよび通信されました。
問題は、これらの言語固有のメカニズムのそれぞれに、異なるロード/アンロードのセマンティクスがあったことです。
たとえば、Ruby は、DLL をメモリにロードした後、Windows FreeLibrary API を呼び出すことは決してなく、複数のインスタンスを非常に困難にしました。
ただし、*プロセス*のセマンティクス、つまり、OS 上のプロセスのライフサイクルを開始、停止、および管理することは、OS が何であれ、すべての言語で驚くほど似ています。
そのため、IE ドライバーの書き換えが 2010 年に完了したとき、開発チーム（私）はそれを別の実行可能ファイルにすることにしました。これにより、使用している言語バインディングに関係なく、ロード/アンロードのセマンティクスを一貫させることができます。
これと同時に、Chromium チームは Opera の先例に倣い、Chrome 用のドライバー実装を提供することを決定しました。
今後、開発、強化、保守を行い、Selenium プロジェクトの Chrome ドライバーの保守の負担を軽減する実装です。

XgizmoX
そして、そのドライバーはブラウザの一部ですか？

jimevans
XgizmoX: そうではありませんが、ChromeDriver 経由で自動化されていることを Chrome 自体が認識する賢さがあるかもしれないと私は信じています。Google の人がそれについて尋ねるのに適任でしょう。
とにかく、共有ライブラリ（.dll/.so/.dynlib）のロードセマンティクスの違いを知って、Chromium チームは（私の勧めで）ChromeDriver の実装を別の実行可能ファイルとしてリリースすることを決定しました。
数年早送りすると、WebDriver を W3C 標準にしようとする努力が見え始めます。
W3C のワーキンググループは、WebDriver の動作と、ブラウザがそのメソッドにどのように反応すべきかを成文化した仕様（まだ進行中ですが、最初のバージョンでほぼ完成に近づいています）を作成しました。さらに、言語バインディングと特定のブラウザのドライバー間の通信に使用されるプロトコルを標準化しました。
これがどれほど重要で画期的であったかを強調することはできません。
W3C とその中の WebDriver ワーキンググループは、ブラウザベンダー自身の代表者で構成されているため、ソリューションがブラウザベンダーによって直接サポートされることが保証されます。
Mozilla は、Firefox 用の WebDriver 実装（GeckoDriver）を作成しました。
言語バインディングの適切なセマンティクスを維持しながら、そのブラウザドライバーを配布するための最も効率的なメカニズムは、別の実行可能ファイルとして出荷することでした。
注意してください、これは GeckoDriver アーキテクチャの非常に大まかな単純化です。実際の実行可能ファイルは、仕様のワイヤープロトコルから内部 Marionette プロトコルに変換する、比較的薄いシムとして機能します
しかし、ポイントは依然として有効です。
とにかく、状況は現在、ブラウザベンダーが提供するドライバーの実装に関して進化しています。Microsoft には Edge 用、Apple には Safari 用（10 以降）、Chromium チーム（主に Google のスタッフ）には Chrome 用、そして Mozilla には Firefox 用があります。
レガシー Firefox ドライバーの今後の有用性を考えると、それを別の実行可能ファイルに分割することは無駄な努力になるでしょう。
これは特に、実行可能ファイルによって通常処理されるすべての通信ビット（言語バインディングからの HTTP リクエストをリッスンして応答すること）が、ブラウザ拡張機能によって完全に処理されるためです。
レガシー Firefox ドライバーを別の実行可能ファイルにする必要は文字通りありません。
さらに、それを言語ランタイムから独立させることは、かなりの作業になります
（.NET ショップは、Firefox を自動化するためだけに Java ランタイムをインストールする必要があることに合理的に難色を示す可能性があるため）
したがって、歴史的に言えば、noob-einsteinsfo、別の実行可能ファイルが標準になった一般的な理由と、そのパラダイムがレガシー Firefox ドライバーを含むように拡張されなかった一般的な理由は、それです。
意味はわかりますか？
わかりました。
さて。
GeckoDriver について。
GeckoDriver の物語は、前述の W3C WebDriver 仕様のステータスと密接に結びついています。
仕様のレベル 1 はほぼ完了していますが、そこに到達するまでに数年の努力が必要でした。
WebDriver オープンソースソフトウェア（OSS）プロジェクトが行ったことの最初のドキュメントを、ブラウザベンダーやその他の実装者が解釈して実行可能なものに変えることができる適切な仕様言語に成形するには、非常に賢明な人々（AutomatedTester もその 1 人）からの多大な努力が必要でした。
GeckoDriver（旧 Marionette）プロジェクトを開始するにあたり、Mozilla は OSS 実装に従うのではなく、仕様のみに基づいて実装することを決定しました。
これにより、仕様言語が完成していなかったため、実装できなかったという、鶏と卵の問題が発生しました。
高度なユーザーインタラクション API（Java および .NET の Actions クラス）に関する言語が実際に実装するのに十分なほど堅牢になったのは、ここ 6 か月ほどのことです。
したがって、それが現在の GeckoDriver での機能の最大の欠落部分です。仕様を介して実装できなかったため、実装されていません。
AutomatedTester と彼のチームがその実装を完了させて利用できるようにすることが非常に優先順位が高いことは知っています。
GeckoDriver が必須であり、3.x で Firefox を自動化するためのデフォルトの実装である理由については、Mozilla によって行われたいくつかの決定にも起因します。

TheSchaf
したがって、必要な機能が欠落している限り、古い FF を使用する以外に選択肢はないと思います
WhereIsMySpoon
TheSchaf: それらの機能が必要な場合は、はい
または別のブラウザを使用する
TheSchaf
moveTo と sendKeys は非常に基本的なはずですが :p

jimevans
TheSchaf: element.sendKeys は正常に動作します。壊れているのは Actions.sendKeys です。
Firefox バージョン 40 いくつか（正確なバージョンを思い出せません）では、Mozilla セキュリティチームによって署名されていないブラウザ拡張機能をブロックする機能が追加されました。
レガシー Firefox ドライバーがブラウザ拡張機能として構築されたことを覚えていますか？さて、ブラウザのその機能が有効になっていると、レガシードライバーをブラウザでロードできませんでした。
さて、いくつかのバージョンの Firefox では、ブラウザのこの機能を無効にして、署名されていない拡張機能を引き続きロードできるようにすることができました。
そして、Selenium は、Firefox の起動時にバインディングが作成した匿名プロファイルで使用される設定のおかげで、これを行いました。
Firefox 48 まで、署名されていない拡張機能のロードを無効にすることができなくなりました。
その時点で、GeckoDriver がそのための唯一の前進方法でした。
さて、あと 2 つのわずかなポイントを述べたら、お話の時間は終わりです。
まず、レガシードライバー拡張機能の性質上、Mozilla セキュリティチームの認証プロセスに合格することは不可能です。
私たちは尋ねましたが、拒否され、二度と起こらないと言われました。
そして、その拡張機能が行うことは、トラックの艦隊全体を運転するのに十分な大きさのセキュリティホールであるため、それは完全に合理的です。
次に、実際には、Firefox 48 以降のバージョンでプライベートにロードおよび使用できるように、レガシー拡張機能にプライベートに署名する方法があるかもしれないことが判明しました。
それでも、それは理想的とは言えないアプローチです。なぜなら、私たちのお祭り騒ぎのオープンソース開発者のグループは、ブラウザを最初に作成した Mozilla の開発チームよりも Firefox をより適切に自動化する方法を知ることができないからです。
特に、GeckoDriver に強制的に移行させられているように感じるときは、レガシー実装の完全な機能パリティがないことに不満を感じることは十分に理解できます。
その決定について Selenium プロジェクトに激怒することは、完全に間違った方向に怒りを向けています。
ただし、Mozilla の決定についてひどいことを言う前に、Mozilla には常にプロジェクトに従事している人が何人かいて、このチャンネルにはそのうちの何人か（AutomatedTester、davehunt など、2 人を挙げます）がいることを知っておいてください。
これらのことの歴史的な詳細の一部をうやむやにしたり、誤って特徴付けたりしたかもしれませんが、喜んで訂正します。結局のところ、私は年をとっており、記憶は以前のようにはいきません。
しかし、友人の皆さん、これが、ドライバーに別々の実行可能ファイルがある理由、GeckoDriver が前進する方法である理由、そして、機能が不足していたにもかかわらず、移行が行われたときに移行が必要だった理由についての（それほど短くない）歴史です。

jimevans は、自分が WebDriver プロジェクトの非公式な歴史家になったように感じています


トランスクリプト: https://botbot.me/freenode/selenium/2016-12-21/?msg=78265715&page=6

リリースを非公式に命名（IRC のチャンネルトピック別）

  • Selenium 2 beta 3 「次世代ブラウザリリース」が利用可能になりました - http://bit.ly/i9bkC2

  • Selenium 2 RC1 「グリッドリリース」が利用可能になりました - http://bit.ly/jgZxW8

  • Selenium 2 RC2 「より良く動作するリリース」が利用可能になりました - http://bit.ly/mJJX1z

  • Selenium RC3 - 「次のは「ビッグ」なリリース」リリース - http://bit.ly/kpiACx

  • Selenium 2.0 Final が予期せぬ大衆に解き放たれました

  • Selenium 2.1.0 が利用可能になりました（はい、Maven ユーザーも利用可能になりました）

  • Selenium 2.2.0 が利用可能になりました（NuGet で..そして、はい、Maven でも）

  • Selenium 2.3.0 が利用可能になりました。新しい伝統！

  • Selenium 2.4.0 がリリースされました – 色々変更がありましたが、まだブログ記事はありません

  • Selenium 2.5.0。うーん。ベーコン。

  • Selenium 2.6.0 が利用可能になりました。自動車保険を切り替えて 15% 以上節約

  • Selenium 2.7.0 の Ruby バインディングが最初に登場（いずれにせよ Twitter で）。Jari は機械だ…

  • Selenium 2.8.0 がリリースされました – 一日前のベーコンはまだベーコンです

  • 悲しいことに、IRC ログがありません…

  • Selenium 2.22: 1 か月間の週刊リリースがついに登場！

  • Selenium 2.23: 「今度はすごい！」ちょっと待って。今？！

  • Selenium 2.24: 今度はさらに、えーと、色々？

  • Selenium 2.25: 順調に追跡

  • 2.26 がリリースされました！

  • Selenium 2.27 が Firefox 17 の修正とともにリリースされました。熱いうちに手に入れよう！

  • （2.28 のトピックの更新はありませんでした）code.google.com/p/selenium が github.com/seleniumHQ/selenium にミラーリングされました - 私たちは今 git に移行しました！

  • 2.29.0 がリリースされました！FF18 サポート付きの最初の git リリース！

  • ドーン！2.31 が Firefox 19 のネイティブイベントサポートとともにリリースされました。

  • 「相関関係は因果関係を意味しません」Firefox 20 サポート付きの 2.32.0 がリリースされました。

  • 米国政府が再び開かれました！FF24 サポート付きの新しくリリースされた 2.36 で祝いましょう

  • 2.40 はすごい自動化、とても多くの修正、とても素晴らしい

  • 2.41 - 最後の IE6 「サポート」リリース

  • 2.45.0 - FF36 サポート付きでリリース

  • 2.46.0 - FF38 サポート付きでリリース

  • 2.47.0 - Edge サポート付きでリリース

  • 2.48.0 - すべての言語で Marionette サポート付きでリリース

  • 2.49.0 リリース - FF 43 サポート付き

  • 2.50.0 リリース - 「すべては血まみれの端のケースだ！」- D.W-H

  • 2.51.0 リリース - 「すべては血まみれの端のケースだ！」- D.W-H

  • 2.52.0 リリース - これで「すべての血まみれの端のケース！」を無効にできます

  • 2.53.0 最後の RC リリース

  • 3.0 クリスマスリリース！FF48 には GeckoDriver が必要になりました

  • 3.6 「金曜日にリリースされなかった」リリース

最終更新日：2022年1月10日: More wiki (#907) [deploy site] (adcf706a1ad)