翻訳記事


Selenium 3がやってくる

2016/10/08 22:35 に 戸田広 が投稿   [ 2016/10/09 3:15 に更新しました ]

[翻訳] 戸田

Selenium 3がやってきます! これを書いている時点では、「beta4」を3.0公式リリース前の最後のベータ版にするつもりです。何が変わるのか、皆さんのテストにどんな影響があるのかを私からお伝えします。

長くなるのでかんたんに

  • WebDriverユーザーにとっては、単なるバグフィックスであり、2.x系からのちょっとした更新となるでしょう。
  • Selenium Gridユーザーにとっても、バグフィックスかつ単なる更新となるでしょう。
  • Seleniumプロジェクトが積極的にサポートしているAPIは、いまやWebDriver APIだけになりました。
  • Selenium RC APIは「レガシー」パッケージに移されました。
  • Selenium RCを支えていたオリジナルコードは、WebDriverを裏で利用するものに置き換えられたうえで、「レガシー」パッケージに含まれています。
  • 時期的には偶然なのですが、MozillaはFirefox 48から、Selenium 2系か3系かに関わらずGeckoDriverが必要になるように変更を入れました。

ではもっと詳しく


2011年にSelenium 2.0をリリースしたとき、私たちは新しいWebDriver APIをご紹介し、移行をおすすめしました。もしあなたがWebDriver APIを使っているなら、Selenium 3.0はただのちょっとしたアップグレードです。公開されているWebDriver APIは何も変えませんでしたし、コードは基本的には2.x系最後のリリースと同じです。あなたがSelenium Gridを使っている場合も同様です。ほとんどの場合では、新しいjarファイルをざっと使う(または、Mavenの依存性設定を3.0.0に更新する)だけで終わりです。

Selenium 3への更新がこんなにぱっとしないのに、なぜ私たちはあえてこれをSelenium 3.0と呼ぶのでしょう? この問いに答えるためにまず、多少の経緯と、Seleniumが内部でどのように動いているのかをお伝えする必要があります。ごく初期のバージョンのSeleniumは、「ただの」非常に複雑なJavaScriptフレームワークであり、ブラウザー内で動作し、Selenium IDEを使っていればおなじみであろう表形式のテストを解釈するものでした。私たちはこれを「Selenium Core」と呼びます。このJavaScriptフレームワークはSelenium RCのオリジナル実装の基礎をなしていました(Selenium RCは最初のSelenium API一式で、すべてのメソッドや機能は「Selenium」インターフェース上にあり、今に至っては非推奨です)。時が経つにつれ、最新のWebテストのニーズはこれまで以上に複雑かつ洗練されたものになってきましたし、Selenium Coreはいまや以前ほどはニーズを満たせないものとなりました。

Selenium 3.0では、私たちはSelenium Coreのオリジナル実装を削除しました。古いRCインターフェースを使いたい方には、内部ではWebDriverを使っている別の実装を提供します。これはSelenium 2の一部機能としてリリースされていた「WebDriver-Backed Selenium」と同じものです。根幹の技術をSelenium CoreからWebDriverに変えたので、みなさんはRC利用の既存のテストにおいて問題になってしまっていた部分に気づくことでしょう。Seleniumスイートの移行で実際に手間となったのは、最小限のエンジニアリング作業で修正できる一般的なシステムの問題となります(つまり、問題はいくつかの場所に正常に分離されていて、修正可能になっているということです)。

私たちはまた、オリジナルのSelenium RC APIを、普段ダウンロードできるファイルから削除しました。Javaユーザーの方でSelenium RC APIが既存のテストの保守のために必要である場合は、依存性設定に「org.seleniumhq.selenium:selenium-leg-rc:3.0.0」(またはこれ以降!)が必要になります。どうしても必要でない限り、これは使わないことを強くおすすめします。Selenium IDEから表形式で出力されたテストを実行される方には、SeleniumプロジェクトのWebサイトからダウンロードできる新しいテストランナーをご用意しています。これは前のテストランナーと同じ引数で動かせますし、出力もまた同様に確保できるようにできるだけのことはしておきました。

SeleniumプロジェクトがSelenium 3.0を世に出すのと同時に、MozillaはFirefoxをより安全に・安定させるために内部を変更しましたが、これによりコミュニティが提供していたFIrefoxDriverはもう動かなくなってしまいました。したがって、テストでFirefoxを使うときは、ChromeDriverやEdge用MicrosoftWebDriverと同様にGeckoDriverを併用する必要があります。Selenium 2を使うときにもGeckoDriverを使わなければならなくなります−変わったのはSeleniumではなく、ブラウザーです。GeckoDriverは進化し続けているW3C WebDriver標準に基づくα版ソフトウェアです。みなさんが最良のテスト体験を得られるように全力でがんばっていますが、Firefoxでちゃんとテストできるようになるまでの道にはどうしてもいくつかのデコボコがあるのです。

今回のリリースはSeleniumのコミッターとコミュニティの多大な努力の集大成です。このプロセスに関わったすべての方、そしてSeleniumプロジェクトの成功に大きく寄与してくださった世界中のユーザーに感謝したいです。

Sauce LabsでAppium1.5がリリースされました

2016/03/29 2:52 に Nozomi Ito が投稿   [ 2016/03/30 2:54 に更新しました ]


Appium1.5

Appiumチームは非常に自信を持ってAppium1.5のリリースをお知らせします。Appium1.5はこれまで半年以上計画されてきましたが,私たちにとってどれだけ重要なリリースなのかを共有させていただきたいと思います。Appium1.5では技術的なアーキテクチャを根本的に見直しています。プロジェクトが揺籃期から1.0に,そしてさらにバージョンを重ねて成長する中で,コアチームはコードが組織化されているよう維持し,新しい貢献者がプロジェクトに入りやすい状態を保ち,時流に応じてバグ修正と機能追加を行うことに注力してきました。しかしながら,多くのソフトウェアプロジェクトと同様に,私たちの努力にもかかわらず,私たちと足並みを揃えるのではなく,私たちに反するようにAppiumの基礎アーキテクチャが機能している時代が来たのです。

バージョン1.4.xは安定していたので,私たちは次代のAppium開発の速さに投資する良い時期だと感じました。Appium1.5の開発では,次の点をゴールに設定しました。

  • 現在のコード構成を厳しく見直し,Appiumの異なるサブセクション間の関係性を,より明確に区別して繋がりを分離する観点から,再び概念設計すること。
  • NPM環境のベストプラクティスを推進し,信頼性や保守しやすさなどの観点からAppiumを複数のパッケージに分割して,常に適切な状態にすること。
  • 全体のコードベースをES5 JavaScriptから,async/awaitのあるES2015 JavaScriptに書き直すこと。(およびAppiumの不具合をトレースしにくくしている巨大なソースも一掃すること)
  • サブプロセス管理を標準化すること。Appiumでは基本的にAPIサーバとサブプロセスマネージャ(私たちが管理しているのは,例えばinstruments, uiautomator, chromedriver, selendroidなどなど)が連携していますので,サブプロセス管理を標準化することでプロジェクトを通じてコードの可読性が向上します。
  • 共通で使われているドライバーの振る舞いを抽象化すること。AppiumのiOSサポートとAndroidサポートは,実は同じ共通インタフェースから派生しています。ですので,私たちはAppiumの異なるドライバー間で存在する動作の重複と定型文を減らすため,そのインターフェースを取り除きたかったのです。
  • ビルドプロセスを整理し,状況に応じて扱いの難しいビルドツールを使い分けなくてもいいようにすること。Appiumのリリース時には,時間を節約するため,サブパッケージレベルでCIを走らせていることを保証すること。
  • 新しくAppiumに貢献してくれる開発者がより親しみやすさを感じるアーキテクチャ環境を創出すること。ある種の変更は,一箇所でかつREADMEが豊富なところで発生する必要があると確認すること。
さらにたくさんの非常に特殊な技術的ゴールが設定されています。開発者の視点から現在どのようにAppiumが企画されているかについて詳しくは,developer's overviewをご参照ください。重要なことですが,私たちのゴールは新しい機能の追加ではありませんでしたので,書き直しは,新機能の追加で曇らされることなく行われていると考えました。内部的には刷新されていながらも,基本的にAppium1.5はAppium1.4.16と全く同じ振る舞いをします。もちろん,ここそこに多少の微調整を入れざるをえませんでした。書き直しの結果,長く放置されてきた,セッション操作を処理する様々な不具合が修正されましたので,私たちはサーバについての議論を非難し,URI経由でAndroidの意図を立ち上げる能力を追加しました。詳細,とりわけ今回のリリースで私たちが実装することにしたいくつかの変更点について,リリースノートをご覧ください。

Appium1.5はオープンソースコミュニティで何ヶ月間もベータ版で公開されていて,私たちは問題を活発に修正してきました。しかし,全てを書き直している以上,自動あるいは手動テストでカバーされていないエッジケースの存在が強く予想されますので,作成中のCIを使用する前に注意喚起しています。つまり,可能な限りハードに扱ってもよいのです。Appiumに関連した不具合はどんなものでもバグトラッカーにご報告ください。Sauce Labsで起こるのにローカルでは起こらない問題については,サポートにご連絡ください。Appium1.5をSauceで使うには,単純にご希望の機能をappiumVersionが「1.5」(この指定方法ですと1.5系のパッチがリリースされると自動的に取得します)もしくは「1.5.0」(こうした特定のリリースを指定する方法ですと,例えば1.5.1などの将来的なアップデートを手動で行う必要があります)にアップデートします。Sauce上で行うテストのためにちょうど求められる機能を取得するための詳細な情報は,Platform Configuratorご参照ください。

Appiumの未来

バージョン1.5はAppiumの将来にとって何か意味しているのでしょうか? かなりたくさんのことを実際に示しているのです! たくさんの新機能を搭載しているわけではないのにもかかわらず,プロジェクト史上の重要なターニングポイントであり,来たる数年間がどうなるかを私たちに提示しているのです。ここでは,Appium1.5で私たちが実現した仕事に基づき,前進することを楽しみにしている幾つかの事柄をご紹介します。

  • Appium開発における進行中の基盤に関わっている個人または企業の貢献者が増えています。今やコードは,より良く組織化され簡単に理解できるバージョンのJavaScriptで書かれており,私たちは新たな貢献者を求めています。もしかしたらあなたを求めているかも? Appiumプロジェクトは@jlippsが率いており,「Appium開発者になるにはでプレゼンが公開されています。お見逃しなく!
  • 技術的な負債を一掃していますので,新しいドライバが素早く効果的に追加されるかもしれません。モバイル自動化技術の趨勢は常に変動しています。Appiumはそれら全ての技術に対する単一のフロントエンドAPIでありたいです。Apple社のUIAutomationを始め,Google社のUiAutomator,さらにSelendroidもサポートしています。しかしそこで満足するつもりはありません。すでにオープンソースコミュニティでApple社の新しいXCUITestフレームワークのサポートであるappium-xcuitest-driverのベータ版が公開されていますし,Google社の新しいUiAutomator 2 frameworkへの対応も始まっています。
  • 不具合が減りました! 書き直しによる一番の恩恵は,醜いコールバックベースの制御フローパターンから読みやすい「async/await」パターンに移行できたことです。今後結果的に分かりにくいリグレッションが減ることを期待しています。
  • 名前の付いたリリースを行うときはセマンティックバージョニンの基準に厳格に則りはじめています。いつAppiumのバージョンをアップグレードして良いかをあらかじめ知る方法を得ることが,「非常に大きな」新機能のためにメジャーバージョンリリースを保っておくという伝統に追随することよりも重要なことだ,ということに皆さんが賛同してくださることを期待しています。例えば,Appiumのバージョン2.0やバージョン3.0が思っていたよりも早く登場したとしましょう。このことは,1.0と1.5の間にあったのと同じくらいたくさんの変化がある,という意味ではありません。単に,これまでいくつかの変更点があったということを意味しているに過ぎません。
常にそうであったように,私たちが今後どうしていこうと考えているかがわかるAppiumプロジェクトのロードマップを確認できますし,現在準備しているリリース内容がわかるマイルストーンも見られます。私たちはAppiumプロジェクトの未来にとてもわくわくしていますし,Sauce Labsで開発を継続しています。続報をお待ちください。

Happy testing!


AndroidとiOSのサポート

2014/02/11 8:18 に Nozomi Ito が投稿   [ 2016/03/25 9:47 に更新しました ]

[翻訳] 伊藤

要約:
私たちは、SelendroidiosdriverAppiumを選択し、Selenium自体が持つAndroidDriverとiPhoneDriverはやめることにする。もしあなたがSeleniumのモバイル向けDriverを使っているのなら、3つのうちどのツールを代わりに使うか判断して欲しい。

長文版:
2007年、Steve JobsがiPhoneを発表し、珍しい存在だったモバイルにおけるWebを、メインストリームの人々が求め利用するものに変えた。現在のトレンドは、モバイルのWebの利用率が遠からずデスクトップからの利用率を上回ることを示している。それが遠回しに言っているのはつまり、モバイルのWebがあなたのサイトにおいて大きな比重を占めるようになり、それらのサイトをモバイルデバイス上でテストするのはとても賢明な考えだということだ。

Seleniumプロジェクトは、iOSとAndroid向けにWebDriverの実装を行うことで、モバイルWebの台頭に対応してきた。iPhoneDriverの最初のコード(iPad上でも動作する)は2009年の初めにプロジェクトに追加された。AndroidDriverは2010年の6月に追加され、主にGoogleのエンジニアによって開発されていた。現在でも、公式のAndroid SDKをダウンロードすると追加ダウンロードオプションの1つに「Google WebDriver」があることが分かる。

モバイルのDriverの最初の取り組みの後、おもしろいことが起こった。このDriverに対する実験的な拡張と修正が、Seleniumプロジェクトの外部で行われたのだ。最初に私が関わったのは、「nativedriver」だ。このツールは、慣れ親しんだWebDriverのAPIを使い、AndroidかiOSかによらず、奇抜なアプローチで、ユーザーがモバイル端末のネイティブUIとやり取りすることを可能にした。最初にこれを見た時、正気の沙汰じゃないと私は思ったが、nativedriverのエンジニアは、これが合理性のあるやり方であることをすぐに私に納得させた。そしてどうなったか?彼らは正しかったのだ。

残念ながら、このアイデアがうまくいくものだと証明された後、NativeDriverプロジェクトは失速してしまったが、このアイデアをモバイルテストツールをうまく動かすための部品として採用した3つのプロジェクトを誕生させることとなった。それがSelendroid、iosdriverそしてAppiumだ。これらはネイティブUIだけでなく、ハイブリッドや純粋なWebのUIのテストも可能だ。最近になり、Windows Phone 8のモバイルWebアプリケーションをテストするWindows Phone WebDriverも加わった。

3つのプロジェクトには共通点がある: それは、メインのSeleniumプロジェクトの同じモバイルのコードに比べて、はるかに活発で、はるかにうまく動作し、はるかに多くのPushがあるという点だ。事実、AndroidDriverとiPhoneDriverの両方に貢献しているSeleniumチームの何人かは、他の3プロジェクトでも活動している。ユーザーが、後でテストを書き直す心配をせずに安心して適切なフレームワークを選べるようにするために、異なるDriver間の相互運用性を維持するための作業も行われている

これはつまり、Seleniumプロジェクト自体のAndroidとiPhoneのDriverをメンテナンスし続けてもユーザーの役に立たないということだ。もっと優れた代わりがあるし、「公式」のDriverがプロジェクト内にあることは混乱を招く。さらにまずいことに、Selenium開発者がこれらのDriverを修正するスピードは遅く、関わる人々はひどく不満を抱いている。このような理由から、SeleniumプロジェクトではこれらのDriverのコードをレポジトリから削除した。そしてユーザーには、他の代わりとなるツールの評価を行うことを勧める。

もちろん、削除されたコードはレポジトリの履歴には残っているので、自分でビルドをしたいのなら、それは今でも可能だ。iPhoneDriverの最後のバージョンはef9d578、Androidのソースの最後のバージョンは00a3c7dだ。ビルドの手間を省くために、このリビジョンからビルドしたAndroidDriverをダウンロードページにアップしてある。

これらの変更は、プロジェクトとしてモバイルをサポートしないという意味ではない。これが意味するところは、私たちはモバイルのWebDriverのベストな実装をサポートし、それらはSeleniumプロジェクトの一部として書かれたコードではない、ただそれだけだ。


モバイルのWebDriver

2014/02/11 8:17 に Nozomi Ito が投稿   [ 2016/03/25 9:47 に更新しました ]

[翻訳] 伊藤

WebDriverのAPIは元々はWebブラウザの自動化のために誕生したのだが、この数年間でモバイルデバイス上でも動作するように拡張されてきた。Appium、iosdriver、Selendroidなどのプロジェクトが、このアプローチがとてもうまくいくことを示した。Webにおいては、Selenium WebDriverをある1つのブラウザ(たとえばFirefox)で使い始め、それを他のブラウザ(たとえばInternet ExplorerやChrome)に切り替えることは容易だ。モバイルでも同様に、Androidの自動化フレームワークから他に切り替えられたら、それは素晴らしいことだ。

Selenium3の開発の一環として、私たちはappiumiosdriver間、appiumとselendroid間の相互運用性を確実なものにするためのテストスイートの作成に着手した。作業を始めるにあたり、各ツールの主な作者たち、Marionetteプロジェクト(Mozillaによる、FirefoxとFirefox OS向けのWebDriverの実装)を代表してDavid Burns、Seleniumプロジェクトを主導するSimon Stewart、といった人々が、ロンドンのMozilla HQにある小さな部屋に2日間閉じこもった。彼らは各プロジェクトでバラバラの領域をすり合わせ、確実な相互運用を可能にする方法について合意した。血と涙は最小限にとどまったが、困難な作業がたくさんあった。

その2日間の議題がこれだ。議事録もある。

こうしている間にも、Google CodeのSeleniumプロジェクトレポジトリにホストされた共有のテストスイートで、作業は始まっている。どうぞ自由に参加して欲しい!


Selenium3のロードマップ

2014/02/11 8:16 に Nozomi Ito が投稿   [ 2016/03/25 9:46 に更新しました ]

[翻訳] 伊藤

Selenium2がリリースされたのは2011年の7月。それから実に2年が経った。Selenium2の主要なバージョンアップであったWebDriver APIは今やW3C標準の基礎となり、Google、Mozilla、Operaによる実装とサポートが行われている。公式にサポートされているJava、C#、Python、Ruby、JavaScriptのリリースは34におよび、コミュニティはPerlやPHPなどの言語バインディングを提供している。コードの修正をした人は57人におよび、数えきれない人がオンラインのフォーラムに参加し、手助けやアドバイスを行っている。

そのような状況の一方で、世界はどんどん進歩し、今やSeleniumプロジェクトが未来の方を向くべき時が来た。現在私たちはSelenium3に向けて開発を進めており、そのように宣言できることをとても嬉しく思う。

私たちは、Selenium3を「ユーザーに焦点を合わせたモバイルとウェブアプリケーション向けのツール」にしようとしている。

これはどういう意味か?モバイルのユーザーにとっては、既存のWebDriver APIをモバイル向けに拡張している多くの異なるプロジェクト間の互換性を高めるために、Seleniumプロジェクトがテストスイートをホスティングするということだ。Appiumios-driverselendroidなどのプロジェクトの開発者たちが、このテストスイートの実現のために作業を進めることになる。

私たちはまた、Seleniumのバックグラウンドのテクノロジーを、できる限り安定した有用なものにする作業を進めている。そのために、Selenium3では、初期のSeleniumコアの実装による実装を削除し、その結果Selenium RCのAPIを非推奨とすることになるだろう。古いバージョンのものは独立したダウンロードとして入手可能だが、極めて緊急度の高い修正を除いて開発はストップする。Selenium RCのAPIは、内部でWebDriverを利用した実装をまだ提供するので、現在あるテストを動かすことは依然として可能だ。しかし、今こそ、これらのテストをWebDriver APIを直接利用したものに移行する時ではないだろうか。

Selenium IDEからテストをエクスポートしてHTML形式のスイートを実行している利用者には、それらのテストを実行できる別のランナーを提供するつもりだが、それらはメインダウンロードで提供されるのと同様、内部でWebDriverを使った実装になるだろう。繰り返しになるが、これまでの実装のものをダウンロードすることは今後も可能だが、3.0がリリースされればそれらの開発はもはや活発には行われない。

現在の計画では、今年のクリスマスまでに3.0の配布を開始するつもりだ。とても楽しいことになるはずだ。


1-5 of 5