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