17日に AMO へ提出した Firefox 版 wasavi が preliminary review を通過し、ギャラリーに現れるようになった。
https://addons.mozilla.org/ja/firefox/addon/wasavi/
一応検索結果としても扱われるが、full reviewed ではないのでたいていリストの一番おしりだ。
17日に AMO へ提出した Firefox 版 wasavi が preliminary review を通過し、ギャラリーに現れるようになった。
https://addons.mozilla.org/ja/firefox/addon/wasavi/
一応検索結果としても扱われるが、full reviewed ではないのでたいていリストの一番おしりだ。
ということでテストを書き始める。正確に言うとテストそのものは jsUnit でやってたものを変換するだけなので、土台を書く。
chrome へのオプションを指定しつつ ChromeDriver を生成するのに、
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
:
DesiredCapabilities cap = DesiredCapabilities.chrome();
cap.setCapabikity("chrome.switches", Arrays.asList("--load-extension=/path/to/extension"));
driver = new ChromeDriver(cap);
と書いたのだが、ChromeDriver を上記のようなコンストラクタで生成するのは deprecated だよ、と怒られる。
これは
import org.openqa.selenium.chrome.ChromeDriverService;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.chrome.ChromeDriver;
:
ChromeDriverService service = ChromeDriverService.createDefaultService();
ChromeOptions options = new ChromeOptions();
options.addArguments("--load-extension=/path/to/extension");
driver = new ChromeDriver(service, options);
と書くのがナウいらしい。
参考: https://groups.google.com/forum/?fromgroups=#!topic/selenium-users/-shBLr8WTq0
ありがとうありがとう。
とりあえず単に Firefox を起動させることはできたので、次に Opera を起動させてみる。
まず classpath に OperaDriver を追加する:
テストファイルで OperaDriver を参照するために import を追加する:
import com.opera.core.systems.OperaDriver;
とりあえずこれだけでいいはず……と起動してみたら、Opera が起動しない。wiki を見ると現在の OperaDriver は、opera.exe の場所を割と決めうちの場所からしか探さないようだ。うちの Opera は C:\Program Files\Opera\current\opera.exe にいるのであった。
これは前述の wiki に書いてあるとおり、DesiredCapabilities オブジェクトに設定を突っ込めば上書きできるので、そうした。これでとりあえず Opera 自体は起動するようになったが、自動的にリモートデバッガが開いて何かをしようとしているところで接続できない云々というエラーを吐いて終了してしまう。どういうことなの。
ここはどうも勘違いしていたようだ。先の記事で Selenium Server は今回はいらないと書いたが、必要のようだ。Firefox で試したら普通に起動したので惑わされた。selenium-server-standalone-2.25.0.jar をダウンロードして、あらかじめ
$ java -jar selenium-server-standalone-2.25.0.jar
などとしてサーバを起動させておくおく必要がある。ただ、せっかく ant で一本化しているのだからサーバの起動と終了も自動的に行わせたい。そこで
http://wiki.openqa.org/display/SRC/Selenium-RC+and+Continuous+Integration
を参考に build.xml にいろいろ追加した。これで Opera も起動した。
ということで Opera でのテスト準備も整った。次は Chrome で、ChromeDriver は
https://code.google.com/p/chromedriver/downloads/list
からダウンロードしてくるわけなのだが。zip が揃っていてとりあえず最新の持ってくればそれに jar が入ってるのかな? と期待したらなんと zip の中身は chromedriver.exe ファイル 1 つなのであった。うん……!? 何かのインストーラなの?
と思いつつ実行してみるとコマンドプロンプト的ウィンドウが開きサーバ的動作を始めたようなログが出てきた。はあ、Chrome 場合はこれをサーバとして使うのね。Chrome にまつわるエトセトラは
http://code.google.com/p/selenium/wiki/ChromeDriver
にまとまっているが、それによると ChromeDriver は子プロセスでサーバを起動するモード、すでに起動してあるサーバと http でやりとりするモード、そして chrome 専用のサーバを起動させるモードと 3 形態の使い方があるようだ。chromedriver.exe は %PATH% が通っている場所に置くか、webdriver.chrome.driver システムプロパティにパスを書いておく必要がある。
とりあえず chromedriver.exe を使う方法で行ってみる。
というわけで、なんとか 3 ブラウザを起動させるところには達した。build.xml の該当部分はこうなった:
あとはテストの骨組みに注力することになる。
wasavi の自動テストは、jsUnit で行っているが、いくつか問題が無いわけではない。過去の記事のとおり、クリップボードを参照する場合など、wasavi の ex コマンドは条件によっては非同期で行われる。しかし jsUnit のテストの仕組みでは非同期的に実行される機能をテストするのは難しい。いやそもそもそのレベルになると “unit” test の域を超えて機能テストになっているのでこれは別に jsUnit の問題ではない。
機能テストのレベルで自動テストするにはどうするか。その方面で有名なのは Selenium だ。これを使ってみることにしよう。
Selenium は java 製のアプリケーションで、ブラウザに対する操作を機械的にエミュレートすることでテストを行う。IE/Firefox/Safari/Chrome と主要なブラウザはサポートされている。そしてなんということか、Opera もサポートされている。現在、操作のエミュレーションの仕組みで区別された Selenium RC (Remote Control) と Selenium Webdriver の 2 種類があるが、前者は公式に deprecated であり、Webdriver 版が最新だそうなのでこちらを使うことにする。ちなみに Opera 向け Webdriver や、Ruby 版の自動テストツールである Watir への対応などは Opera 社自らが手がけているみたい。
さてテストは基本的には java で記述し、コンパイルし、実行するが、その API は他の言語へのバインディングも提供されている。しかし wasavi のビルドですでに ant を使っているので、素直に java で書くことにしよう。ant のタスクに junit そのものがあるので、単にそれを呼ぶだけで済む。
ゴール
Selenium を用いた自動的な機能テストを行えるようにする。テストは
$ ant runtest
のように ant のターゲットの 1 つにする。
必要なファイル
http://seleniumhq.org/download/ からダウンロードしてくる。さまざまなファイルがあるが、
また、JUnit の jar も必要なのでもらってくる。github にさまざまなファイルが置いてあるが、最新の snapshot はとりあえず避けて junit-4.10.jar を使うことにする。
ファイルの配置
+ wasavi
+ wd-tests
+ src
+ dst
+ libs
+ selenium-2.25.0
+ junit
こんな感じで配置。テストは src の下に置き、.class は dst の下に置く。
build.xml への追加
こんな感じで追加。とりあえず独立したターゲットにしたが、ビルドプロセスの間に行うようにしても良いだろう。
テストを書く
import org.junit.*;
import static org.junit.Assert.*;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
public class WasaviTestSuite {
private static WebDriver driver;
@BeforeClass
public static void beforeClass () {
driver = new FirefoxDriver();
}
@AfterClass
public static void afterClass () {
if (driver != null) {
driver.quit();
driver = null;
}
}
@Test
public void foobar () {
assertTrue("TestExample", true);
}
}
とりあえず Firefox を起動させてみる。あと、実際にはテストは複数ファイルに分かれるのでテストスイートにしないといけない。なんか junit4 になったらいろいろ変わりすぎてて困る。
とりあえずここまで。
textarea 要素を vi として振る舞わせるエクステンション。ただし、現在はメンテされていないものが多い。特に Firefox は 3.6 あたりで軒並み古いエクステンションを切り捨てているようなので、公開した当時のままのエクステンションは分断されている。
いずれも textarea に対して直接キーボードイベントハンドラを仕掛けて、自前の制御を行っている。また、ex コマンドに類するものはほとんど実装されていない。
Firefox 版 wasavi のレビューがなされた。もちろん rejected。
まず innerHTML 使うなボケ! ということである。wasavi.js では大まかに分けて 3 箇所、innerHTML を使っている箇所がある。ひとつめは、wasavi 本体の iframe 内で、
document.body.innerHTML = wasaviFrame;
として wasavi の骨組みを組み立てている。ここで wasaviFrame には、body 以下の骨組み全体となる html の文字列が入っていて、バックグラウンドから送られてくる。バックグラウンド側ではこの文字列は、エクステンションのアーカイブ内から読み出す。
この innerHTML の操作を DOM のメソッドを使用して要素ずつ組み立てる処理に置き換えるのは、ちょっとコストが高すぎる。また、前述の通り内容が外部から操作されるというものでもない。したがってこの箇所については、innerHTML の使用は問題ないはずだ。そういうことを説明することにしよう。
ふたつめは、wasavi が拡張する対象となる textarea 要素の value を wasavi へ複製する際。
var html =
'
';
this.elm.innerHTML = html;
こんな感じ。こちらは、textarea_value に入ってるものがページとユーザ次第のものなので、確かに innerHTML 経由だとセキュリティリスクが生まれる余地がある(上記の事前のエスケープを回避する方法はちょっとすぐには思いつかないが……)。というわけで、こちらは \n で分割した textarea_value を逐一生成した div の textContent に突っ込むようなループに変更した。これはテキストが 1 万行とかになるとパフォーマンスの問題が出てくるかもしれない。
最後に、さまざまな要素の内容を生成する際に
elm.innerHTML = '';
とやっている箇所がいくつかある。これにはセキュリティリスクが入り込む余地はないと思うが、DOM Range を用いて内容を消去するように変更した。
function emptyNodeContents (node) {
var r = document.createRange();
r.selectNodeContents(node);
r.deleteContents();
r.detach();
}
innerHTML 関連は以上。
次に、javascript 内で他の javascript ソースを読み込むのに
document.write('