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.