eyecatch
Mon, Aug 14, 2017

WebdriverIOとChromeのヘッドレスモードで自動ブラウザテストするDockerイメージ: webdriverio-chrome

「2017年夏、ブラウザテストフレームワーク」の続き。 ServiceNowアプリケーションのブラウザテストをしたくて色々調べている。 前回は、フレームワークにWebdriverIOを使うと決めたところまで書いた。 今回、最終的に、WebdriverIO、WDIO、selenium-standalone、Jasmineと、Chromeのヘッドレスモードを使って、Dockerコンテナ(Alpine Linux)上でテストスクリプトを実行して、ServiceNowのログイン画面のスクリーンショットが取れるところまでできた。 そのコンテナイメージのDockerfileはGitHubに置いた。 (adsbygoogle = window.adsbygoogle || []).push({}); とりあえずAlpine Linux テスト環境の作成は自宅でやってるけど、DockerイメージにしてDocker Hubとかに上げておけば、社内でダウンロードしてそのまま再現できる。 ダウンロードに係る社内手続きも、Dockerイメージだけに対してやればいいので、中に何を詰め込んでも、後でライブラリとか追加しても、一回こっきりで済む。 というわけでとりあえず、自PC(Windows 10 Home)に入ってるVMware Workstation Player 12.5.5でCentOS 7 x64のVMを作り、Dockerをインストールして、Alpine Linuxをpullした。 $ docker pull alpine:edge Alpine LinuxはBusyBoxとmusl libcで構成された軽量な Linuxディストリビューション。 2016年2月にすべてのオフィシャルDockerイメージがAlpine Linuxベースになるというアナウンスがあったし、他にそれっぽいものもなかったので、これをベースに環境を作ることにした。 glibcじゃないのがちょっと気になるけど、まあ問題ないか。 現在、Chrome 59のAlpine Linuxパッケージがedgeブランチで作られているので、Alpine Linuxはedge(i.e. 開発中のバージョン)をpullした。 (因みに現時点でAlpine Linuxのlatestは3.6。) で、起動。 $ docker run -it alpine:edge sh Chrome(Chromium)インストール まずはChrome(がAlpine Linuxパッケージにはないので、実際にはChromium)と、ついでにChromeDriverをインストールする。 Alpine Linux独自のパッケージマネージャーであるapkを使う。 / # apk add --update chromium chromium-chromedriver / # chromium-browser -version Chromium 59.0.3071.115 無事インストールできた。 この記事を参考にヘッドレスモードで実行してみる。 ヘッドレスモードにするために--headlessを付けて、一時的な制限事項で--disable-gpuを付ける必要があって、コンテナの権限不足を回避するために--no-sandboxを付ける。 (コンテナの権限不足回避には他に、docker runに--privilegedや--cap-add=SYS_ADMIN付ける方法がある。) / # chromium-browser --headless --no-sandbox --disable-gpu https://example.com/ [0811/145902.894023:WARNING:dns_config_service_posix.cc(326)] Failed to read DnsConfig.
eyecatch
Fri, Aug 4, 2017

2017年夏、ブラウザテストフレームワーク

「2017年夏、Selenium、ヘッドレスブラウザ」の続き。 ServiceNowアプリケーションのブラウザテストをしたくて色々調べている。 前回は、Selenium(WebDriver)とChromeのヘッドレスモードを使うのがよさそうというところまで書いた。 この記事では、ブラウザテストフレームワークを選ぶ。 (adsbygoogle = window.adsbygoogle || []).push({}); ブラウザ操作ツールとかブラウザテストフレームワークとか Seleniumを直接使って、JUnitなんかのテストフレームワークでブラウザテストを書くこともできるけど、それは結構つらい。 Seleniumは低レベルなブラウザ操作APIを提供するので、単純にテスト書き辛いし、動的サイトを扱うときには、かなり気を使ってwait処理を入れていかないとテストが安定しない。 テスト前に、WebDriverの準備をしないといけなかったりするのも面倒。 なので、昨今はもう少し高級なツールやフレームワークを使うのが普通な模様。 あまり知らなかったので色々記事を読んだ。 Seleniumアレルギーのための処方箋 ブラウザテストツール総まとめ・2016年夏版 2017年JavaScriptのテスト概論 結果、ブラウザ操作ツールやブラウザテストフレームワークには以下のようなものがあることが分かった。 (SeleniumやWebDriver系じゃないのも含む。) Nightwatch.js GitHubの★は6835。 JavaScriptでブラウザテストを書けるフレームワーク。 WebDriverプロトコルに対応していて、Seleniumと異なる独自のクライアントAPIを実装。 つまり使えるブラウザの幅が広い。 テストフレームワークは独自のもの。 WebdriverIO GitHubの★は3217。 JavaScriptでブラウザを操作できるツール。 WebDriverプロトコルに対応していて、Seleniumと異なる独自のクライアントAPI(ラッパ?)を実装。 つまり使えるブラウザの幅が広い。 独自のテストランナであるWDIO付きで、テストフレームワークにMocha、Jasmine、Cucumberなど、いろいろ利用できる。 Protractor GitHubの★は6801。 JavaScriptでブラウザテストを書けるフレームワーク。 WebDriverプロトコルに対応していて、selenium-webdriverをラップしたAPIを提供する。 WebDriverなのでブラウザはなんでも。 テストフレームワークは、Jasmine、Mocha、Cucumberのほか、いろいろ選べる模様。 AngularとAngularJS向けだけどそれ以外にも使える。 Google製なので信頼感があるし、ドキュメントもコミュニティもしっかりしてる。 Casper.js GitHubの★は6337。 JavaScriptでブラウザテストを書けるフレームワーク。 使えるブラウザはPhantomJSかSlimerJSだけで、多分WebDriver使ってない。 テストフレームワークは独自のもの。 Nightmare GitHubの★は12964。 JavaScriptでブラウザを操作できるツール。 ブラウザは、昔の1系はPhantomJSを使ってたけど、今の2系はElectron。 WebDriverは使ってないはず。 テストフレームワーク機能は付いてないけど、同じ作者のNiffyというNightmareベースのツールがちょっとそれっぽい。 TestCafe GitHubの★は3029。 JavaScriptでブラウザテストを書けるフレームワーク。 すごい多機能っぽいし、TypeScriptやasync/awaitをサポートしててなんかモダン。 WebDriverは使ってないっぽいけど、Chrome、Firefox、IE、Edge、Safariなど、一通りのブラウザが使える。 なぜかリモートテストもできる。 どうもSelenium 1みたいにJavaScriptコードを挿入してテスト実行するらしいんだけど、よくわからない。 Zombie.js GitHubの★は4608。 JavaScriptでjsdomを操作できるツール。 なぜか妙にアサーション機能に凝っている。 WebDriverは使ってないはず。 Chromy GitHubの★は294。 JavaScriptでChromeを操作できるツール。 chrome-remote-interfaceをラップして、 NightmareっぽいAPIを提供する。 WebDriverは使ってない。 Codeception GitHubの★は2900。 PHPUnitとSeleniumをラップして、ユーザ視点のブラウザテスト(受入テスト)をPHPで書けるフレームワーク。 Capybara GitHubの★は7937。 Seleniumをラップして、ブラウザテスト(受入テスト)をRubyで書けるフレームワーク。 テストフレームワークはRack::Testを始め、いろいろ選べる模様。 Geb GitHubの★は759。 Seleniumをラップして、 JUnitやTestNGと連携して、ブラウザテストをGroovyで書けるフレームワーク。 Selenide GitHubの★は555。 Seleniumをラップして、ブラウザテストをJavaで書けるフレームワーク。 これらよりさらに高級なツールに、CodeceptJSというのがあって、これはJavaScriptでユーザ視点のブラウザテスト(受入テスト)を書けるフレームワーク。 基本的にはMochaとWebdriverIOをラップして、より抽象的なAPIを提供する。 WebdriverIOをProtractorとかNightmareとかAppiumに代えられて、色んな環境のテストが統一的なAPIで書ける。 すごいけどバグを踏んだ時辛そう。 また、ブラウザテストの文脈でよく名前が出るKarmaは、テストフレームワークではなくて、HTTPサーバを起動して、テストを実行するためのHTMLを生成して、ブラウザを起動してそれを読み込んでくれたりするツール(i.e.
eyecatch
Wed, Jul 12, 2017

2017年夏、Selenium、ヘッドレスブラウザ

現在仕事でServiceNow上で動くアプリケーションを開発していて、それのブラウザテストをどうやろうかというのを少し考えたので、書き残しておく。 (adsbygoogle = window.adsbygoogle || []).push({}); ServiceNowとは 本題とほとんど関係ないけど、一応ServiceNowに簡単に触れる。 ServiceNowはITサービス管理のSaaS。 世界的にはITサービス管理のデファクトスタンダードとなっているが、日本ではこれから盛り上がりそうといった感じ。 アプリケーションを開発するプラットフォームとしての側面もあり、JavaScript(ブラウザ側とサーバ側両方)でServiceNowの機能を拡張し、他システムと連携させたり処理を自動化したりできる。 アプリケーションがServiceNowプラットフォームで動くので、テスト方法が悩ましい。 Automated Test Frameworkというテストフレームワークが提供されてはいるが、2017年1月にリリースされたばかりということもあるのか、機能がしょぼく、大したことはできない。 これが自前でブラウザテスト環境を作ろうと思った理由。 アプリケーションがJavaScriptなので、テストもJavaScriptで書きたい。 ブラウザテストとは ここでブラウザテストとは、稼働しているWebアプリケーションに、HTTPクライアントで接続して、レンダリングされたWebページを操作して実行する自動E2Eテストのこととする。 HTTPでWebコンテンツを取得して、HTML・CSSをパースしてレンダリングして、JavaScriptを実行するツール、つまりWebブラウザを何にするかというのと、それを自動で操作するのをどうするかというのと、テストどう書くのかということと、書いたテストをどう実行するかということと、テスト結果をどう集計してレポートするかといった辺りを考える必要がある。 Qiitaの記事「ブラウザテストツール総まとめ・2016年夏版」にブラウザテストのためのツールが色々載っている。 レイヤや目的が異なるツールがちょっとごっちゃになってる気がするけど。 SeleniumとかWebDriverとか ブラウザテストはWebDriver抜きでは語れないので、とりあえずそれについて書く。 それにはまずSeleniumについて語らなければなるまい。 ブラウザテスト創世記にはこうある。 神は「光あれ」と言われた。 するとSeleniumがあった。 神はその光を見て、良しとされた。 神はその光と闇とを分けられた。 神は光をSelenium RC (aka Selenium 1)と名づけ、 闇 をSelenium WebDriver (aka Selenium 2)と名づけられた。 (Seleniumの歴史をもっとちゃんと知りたければこの記事を読むべし。) 要は、今ブラウザテストと言ったらSelenium、Seleniumと言ったらSelenium WebDriverというわけだ。 Selenium WebDriverは、WebDriver APIでブラウザやDOMエレメントを操作するツール。 このAPIを実装したクライアントライブラリが各言語(Java、Ruby、Python、JavaScriptなど)で提供されていて、テストコードから利用できる。 APIの裏ではドライバなるものが暗躍していて、OSやブラウザのネイティブAPIを使ってブラウザを操作している。 このドライバはブラウザごと(Chrome、Firefox、IEなど)に用意されていて、その実装形式がドライバ毎に割と違っている。 例えばFirefox用のやつ(Firefox Driver)はFirefox のアドオンを使うし、Chrome用のやつ(ChromeDriver)は独立したネイティブアプリを介してブラウザを操作する。 ドライバは(基本的に)ブラウザと同じマシンにある必要があり、実行するテストコードとも(基本的に)同居している必要がある。 テストを実行するマシンとは別のマシンのブラウザでテストしたければSelenium Server (aka Selenium Standalone Server)を使う。 Selenium Serverはブラウザとドライバと同じマシンで動き、テストコードから送信されたブラウザ操作コマンドを受信してドライバに伝える、プロキシ的な働きをしてくれる。 Selenium Serverを使えば、クライアントライブラリが対応していないドライバでも利用できるというメリットもある。 Selenium Serverを使うと、オーバーヘッドはあるけどメリットが多いので、とりあえず使うようにしておけば間違いなさそう。 Selenium Serverが受け取るブラウザ操作コマンドは、HTTPでJSONデータとして送信される。 この辺りの通信は、もともとJsonWireProtocol (aka
eyecatch
Sat, Jun 10, 2017

git rebaseを図解する

この記事を読んだ、またはGitのオブジェクトモデルを理解していることを前提に、Gitの git rebase というコマンドについて説明する。 このコマンドは、コミット履歴を改変できるGit特有のコマンドで、分かり辛いGitコマンドの中でも最も分かり辛い部類のものだ。 Gitの最後の関門と言えよう。 けど、それだけに使いこなせばとても便利なものでもある。 (adsbygoogle = window.adsbygoogle || []).push({}); git rebaseがもつたった一つの機能 git rebaseにはいろんなオプションがあって、ちょっと調べただけだと、コミットを移動する機能とコミットを修正する機能の二つがあるように見えるかもしれないが、実際は単一の機能しかないシンプルなコマンドだ。 その機能とは、指定した範囲のコミットが含む変更を、別に指定したコミットのコードベースに適用するというもの。 コマンドの基本形は次のようなものだ。 $ git rebase --onto master dev bugfix このコマンドは、bugfixから辿れるコミット群から、devから辿れるコミット群を除いたコミット群が含む変更を、masterのコードベースに適用する。 と書いても分からないので図解する。 このスライドを見ると、git rebaseに指定した3つのブランチのそれぞれの使われ方が分かるはず。 git rebase --onto master dev bugfixが実行する処理をもっと正確に言うと、 bugfixをcheckoutして(i.e. HEADをbugfixにして)、 dev..HEADのコミット群が含む変更を、それぞれ仮領域にパッチとして保存して、 git reset --hard masterして、 仮領域に保存した変更を、HEADが指すコミットのコードベースにひとつひとつ順番に適用する。 上記コマンドでbugfixのところを省略すると、ステップ1のcheckoutが省略される。 言い換えると、上記コマンドは次の二つのコマンドに分解できる。 $ git checkout bugfix $ git rebase --onto master dev さらに、--onto masterを省略すると、ステップ3のreset先が変わり、devになる。 このときのコマンドの形は、 $ git rebase dev という見慣れたものになるが、これが最初に挙げた基本形の省略形だと認識しておくと応用が利く。 以下にgit rebase devの動きを細かめに図解する。 インタラクティブモード 前節のスライドに書いたパッチの適用をカスタマイズできるのがインタラクティブモードで、これは-iオプションで有効にできる。 インタラクティブモードを使うと、パッチをスキップしたり、順番を変えたり、まとめたり、分割したり、編集したりでき、またパッチとパッチの間に任意のコマンドを実行でき、例えばパッチごとにユニットテストを実行できたりする。 インタラクティブモードの使い方についてはググればたくさん出てくるのでここには書かない。