brushing up the tests

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/ からダウンロードしてくる。さまざまなファイルがあるが、

  • Selenium IDE: Firefox で動くプラグインで、ブラウザの操作をインタラクティブに記録していろんな言語によるテストスクリプトにエクスポートできるとか。今回は関係ない
  • Selenium Server: テストを行うマシンを別に誂える場合にサーバ機能を担当するアプリケーション、だと思うけど今回は関係ない。ちょっと勘違いしていた。これも必要。
  • The Internet Explorer Driver Server: 字の通り IE でテストする際に必要なもの。32bit 版と 64bit 版があるので Selenium 本体とは別になっているのでしょう、たぶん。もちろん今回は関係ない
  • Selenium Client Drivers: ローカルマシンでテストする際に必要な Selenium の本体。今回必要なのはその java 版なのでそれを落とす
  • Third Party Browser Drivers: Opera 版や Chrome 版の Webdriver。Selenium 本体を落とせばこれらの個別の Webdriver を含んでいるようなので、たぶん落とす必要はないと思う。ただし各ドライバが個別にアップデートされることはありえるのでそのときは必要かも
  • その他のファイル: とりあえず今回は関係ない

また、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 になったらいろいろ変わりすぎてて困る。

とりあえずここまで。

review rejected #3

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 =
'

' + textarea_value
.replace(/&/g, '&')
.replace(//g, '>')
.replace(/\r\n/g, '\n')
.replace(/\u007f/g, '\u2421')
.replace(/[\u0000-\u0008\u000b-\u001f]/g, function (a) {
return String.fromCharCode(0x2400 + a.charCodeAt(0));
})
.replace(/\n/g, '\n
') +
'\n

';
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('