escape

[cci]s[/cci]コマンド中にバックスラッシュによるエスケープシーケンスを含んだコンポーネントを含めると正しく引数が解析されないのを修正。

つまり、[cci]:%s/$/ \\/g[/cci] みたいなのが正しく動作しなかった。

そろそろ各ブラウザの公式エクステンションストアに置いてるwasaviをアップデートする頃合いだ。

 * * *

アップデートした。今年はこまめにストア版もアップデートするようにがんばるぞい。

Extend the “writeas” effect

wasaviはtextareaの他にcontenteditable属性の付いた要素も編集できるわけだが、そういう要素にどのように中身を埋めていくかはサイトによって異なり、統一されたものはない。そういうわけで、writeasというオプションを用意している。これには以下の値を割り当てられる:

  • html — バッファの内容を markdown とみなし、html を構築する(デフォルト)
  • div — 各行につき div 要素を生成する
  • p — 各行につき p 要素を生成する
  • textAndBreak — 各行につきテキストノードを生成し、改行として br 要素を追加する
  • plaintext — バッファ全体を単体のテキストノードにする

issue #156でこの割当をサイトごとにできないかという要望があった。なるほど確かにそのほうがいいだろう。同様にサイトごとに動作を割り当てられる設定としては、wasaviの起動をさせないためのブラックリストがすでにある。こちらはさらにサイトの下にCSSセレクタを指定できるようにしてあり、個別の要素のレベルで制御が可能だ。writeasもそのようにすべきだろう。

具体的にはwriteasに対して上記の値の他に、JSONとしてパース可能な文字列を与えることを許す。このJSONは例えば:

{
"http://example.com/*": "div",
"http://example.net/*": [
{
"selector": "#element-id",
"writeas": "textAndBreak"
}
]
}

と言った感じの連想配列になり、URLに対するwriteasの値、あるいはURLおよびセレクタに合致する箇所のwriteasの値が取られる。

ところで、ブラックリストはwasaviのオプションではなくwasaviの起動前の設定である。この区別はとても重要だ。本質的にwasaviの設定はwasaviのsetコマンドから操作できるのが望ましい。そういうわけに行かないものだけが起動前設定として独立されるべきである。起動前の設定というのは他にexrcや、起動ショートカットや、起動時の効果音などだがこれはまさにwasaviが起動する前に処理される事柄なのでwasaviの設定からは「止むを得ず」独立させてあるということだ。それ以外の設定、つまりwasaviが起動した後に参照される設定はすべてwasaviのオプションにしてある。とこのように厳密に区別しているのである。さて今回の変更を施す場合、URLごとのリストという点ではブラックリストと似たものになるのだが、しかしいつ参照されるのか? という点で考えるとwriteasは依然としてwasaviのオプションだ。そういうわけで独立した設定にはしない。

ということは、上記のようなJSONをwriteasに代入する際は

set writeas='{ \
"http://example.com/*": "div", \
"http://example.net/*": [ \
{ \
"selector": "#element-id", \
"writeas": "textAndBreak" \
} \
] \
}'

という感じのexコマンドになるのだが、これはこれで改行のエスケープがすごく冗長だ。これはちょっと何とかしたい…。

Showing a newline mark

viにはlistオプションというものがあり、それをオンにすると

  • 行の末尾に [cci]$[/cci] が表示されるようになる
  • タブ文字が [cci]^I[/cci] で代替表示されるようになる

となる。この内、行末尾の表示について実装したい。残念ながら、タブ文字の代替表示は難しい。

ここで行末尾を示すために文字 [cci]$[/cci] が用いられるというのは、vi が端末上のテキストエディタだからで、wasavi の場合はもうちょっと表現力があるので別の記号にしたい。

行末尾、つまり改行を示すための記号というとまあだいたいこんな感じだと思う。特に日本産のエディタでこれじゃない奴はないのではなかろうか。あと、MS Word。海外産だと行をパラグラフとみなして、Pilcrowが多いかもしれない。まあどちらでもいいけれど、とりあえず前者を使うことにしよう。

ところで、改行マークを表示することに意味があるとは特に思えない。それが役に立つのは、行末に余計な空白文字を残している、いわばダーティというか、非正規な状態の行を目視で確認したい場合くらいだろう。そういう行を正規化したいのなら目視確認なんてせずに正規表現による全置換すればいいだけの話で、改行マークを表示することに意味はない。また、正規化済みの行は空白ではないグリフの直後に改行があることが自明なわけで改行マークを表示する必要はなく、非正規な状態の行だけその旨を表示するようにすればいいのだが、非正規な行の場合でも本来強調表示すべきは行末の余計な空白文字であって、改行マークではない(vimの場合で言えばlistcharsに対してeolではなくtailだけ設定した状態)。従っていずれの場合でも改行マークを表示しなければならない積極的な理由はないように思える。

と、そう考えればそうなのだが、実は去年はあんまりwasaviの開発を進められなかったのでいまいち内部の構造を忘れかけているのであった。そのリハビリのためにあえて実装してみる。

ということでこうなった。

Old and New

調べものの途中でたまたま常用漢字の新字体と旧字体の なるものを見ていたのだが、この旧字体で文章を組むとどんな感じなのかしらん? とふと気になったので、ひとまず赤福プラスに組み込んでみた。


なかなか味わい深い。

当初は投稿時のコメントを旧字体に変換するようにしたのだが、「なんで旧字体なの」「うぜえ」などと、ID を出されて火炙りにされそうな勢いだったのでローカルでの表示のみを旧字体に変換するようにした。

この機能は開発バージョンでのみ有効で、オン・オフの設定もない。

The Space

qeema 内でデグレードしてた箇所があったのを修正。Chrome で、IME がオンの状態でスペースキーを押すと(設定によっては)いわゆる全角スペース(U+3000、IDEOGRAPHIC SPACE)が直接入力されるわけだが、それが wasavi に正しく伝達されなくなっていた。

この全角スペースの直接入力に対して Chrome が発生させるキーボードイベントは実におかしい。

  • まず keydown イベントが発生する。この時、keyCode は 229 で入力されつつある文字が全角スペースだという判断には使えない
  • 各種 Composition Events は一切発生しない
  • input イベントが発生する。このイベントは単に通知のためのもので、何が入力されたかという情報は与えてくれない

という感じに実におかしい。Firefox であれば正しく Composition Events が発生する。IME まわりは Firefox の方が Chrome よりずっと真っ当だ。

対応策として、input 内でなんとかするしかなく、実際そうしている。keydown でその時点での対象の要素の値を保存しておき、input で差分を取ってイベントを生成させる。デグレードしたのはその処理が正しく呼ばれていなかった。

Testing with selenium javascript binding #5

ところで Opera ではどうなのだろうか。Blink Opera でも operadriver というものを経由してテストすることになっている。これはつまりchromedriver のフォークだ。じゃあ、だいたい Chrome のように動くと考えていいのかな。

と思ってやってみたらまるでさっぱり動かない。Opera 自体は起動するものの、
exception: Error: ECONNREFUSED connect ECONNREFUSED 127.0.0.1:46266
なる例外が発生してテストが始まらない。

Selenium のライブラリと *driver との接続は http による REST だ。つまり、operadriver 側でリモートコントロールのための接続の listen をしてくれないということなのか?

とそういうわけで現在のところの各ブラウザの selenium 対応は Chrome、Firefox、Opera の順で甲乙丙のようだ。

Testing with selenium javascript binding #4

そういうわけで Linux 上では WebExtensions 版の wasavi の、Selenium による、Firefox 上の機能テストを一通り通せるようになったのだが、結局これを Windows 上ではできていない。過去の記事で何度か書いているが Windows では既存のプロファイルでもって Firefox を起動させることができず、かつ新規プロファイルに WebExtensions ベースの拡張を登録させつつ Firefox を起動させることもできない。両方できないと身動きが取れない。

実を言うと Linux 上でもテストが問題なく滞りなくできてるわけではない。例えば:

  • なにかが leak してますよ〜的なログがいっぱい出る。
    (node) warning: possible EventEmitter memory leak detected. 11 listeners added.
    云々。このエラー自体は書いてあるとおりのそのままの意味なんだろうけど、Chrome でテストする際は出ないので Selenium 内の Firefox とのやり取りをするコードにおける問題だと思う
  • wasavi でテストする際は当然ながら様々なキーストロークを発生させる必要がある。で、[cci]selenium.Key.chord()[/cci] というものがあり、[cci]chord(Key.CONTROL, ‘c’)[/cci] などと呼ぶと ctrl+C を押されたとブラウザに振る舞わせるような擬似的なキーストロークを生成する。Key[なんとか] は、型自体は普通の string で、Unicode の Private Use Area 内の文字である。chord 自体は単に引数を全部 join(”) したものに Key.NULL をくっつけたものを返す。したがって擬似的なキーストロークもまた単純な文字列である。さてそういうルールのもとに構成された chord を送出したあと、geckodriver かあるいは Firefox 本体が例えば前述の例だとそれを ctrl+C としてデコードしてくれないと困るわけなのだが。困ったことに、誰もデコードしてくれない。そのまんま PUA が入力され、テストは失敗する。ひどい
  • テスト中 Web Content なるプロセスが生成されて、これが60〜80%の CPU パワーを消費する。同時に Firefox 自体のプロセスが残りの CPU パワーを消費する。そんなわけでテスト中は待ってる以外にほとんど何もできないし、そもそも端末以外のアプリケーションを全て落とした状態じゃないとテスト自体がうまく始まらない。Chrome を起動しながらとか成功した試しがないのである。そして CPU パワーはめちゃくちゃ食いまくる割にテストの進行は Chrome でのそれより 2 割増しくらいで遅い

前述のプロファイル関連の不具合と合わせて、どーにもこーにも…… Firefox が絡む Selenium のテスト環境はいつも質が悪い、質が低いと言わざるを得ない。どうなってんのかなあこれ……。この辺が快適になってくれないと、Firefox 向けの拡張を作るという事自体にくじけてしまいそうなのだけど。

Testing with selenium javascript binding #3

テストを開始しても、Chrome は起動するもののテストページへのナビゲーションが発生せず、そのままタイムアウトで失敗してしまうことがたまにある。これの原因がよくわからない。とりあえずエラーメッセージとしては “unable to discover open pages” というものが返される。

原因はよくわからない。テスト用とは別の常用の Chrome を起動している状態でテストを開始すると、そういう状況が発生することがあるが、しないこともある。常用の Chrome を落とした状態でも発生することがある。また youtube とかの動画を再生中だと発生する確率が上がるような気がしないでもない。要するに chromedriver が Chrome を起動するものの、複数ある Chrome のうち自分が起動させたものを見失うことがある、というような感じなのだが……そんなわけあるかいな。

上記のエラーメッセージでググっても特にこれだというものもない。謎。

ちなみに Linux 版の Chrome で UI のロケールを任意のものにするには、[cci]LANGUAGE=en google-chrome[/cci] などとする。LANG でも LC_ALL でもなく、LANGUAGE。また、[cci]–lang[/cci] スイッチは効かない。

 * * *

というわけで、とりあえずすべての機能テストを java から javascript へ移植した。疲れた。次にこれを Windows 上の Firefox にて通してテストする。とその前に、Linux 上でも動かしてみよう。

ナウい Firefox で Selenium のテストをするには、geckodriver が必要なので、これをパスの通ったところに置いておく。


var options = new firefox.Options();
options.setProfile(profilePath);
result = new webdriver.Builder()
.withCapabilities(webdriver.Capabilities.firefox())
.setFirefoxOptions(options)
.build()

こんな感じで起動。これは既存のプロファイルを利用するような動作を意図しているが、どうも既存のプロファイルを /tmp あたりにまるごとコピーしてから起動するような感じがする。そのため実際に Firefox のウィンドウが表示されるまでは結構待たされる。

それから、webdriver.actions().sendKeys().perform() が未実装なのだそうでエラーになる。その代わり WebElement#sendKeys() を使う。geckodriver 自体が新しいプロジェクトなので、すべての想定された機能が実装されるまでにはもうちょっとかかる雰囲気。

 * * *

結局のところ wasavi でテストするには

  1. [cci]npm install -g selenium-webdriver[/cci]
  2. [cci]npm install -g chromedriver geckodriver operadriver[/cci]
  3. [cci]npm install -g mocha[/cci]
  4. [cci]npm install[/cci]

と入れて、[cci]make run-chrome[/cci] としてとりあえずテスト用プロファイルでもって起動し、開発者モードで wasavi を組み込み、ついでに dropbox などに wasavi からアクセスして認証を得ておき、ブラウザを閉じてから [cci]make test-chrome[/cci] とする……という感じ。ただし Firefox に関しては、過去の記事の通りオンザフライで WebExtensions ベースの拡張を登録するのが現在のところできないので、wasavi をビルドした上で xpi を登録したプロファイルを用意する必要がある。

Testing with selenium javascript binding #2

mocha のテストをすべて終えると最後に結果が表示される。こんなふうに:

basic test -- 2 tests, 50.00%
--------------------

1 passing (2s)
1 failing

1) basic test should get the title of test frame page:

AssertionError: 'wasavi test frame' == 'wasavi test frame?'
+ expected - actual

-wasavi test frame
+wasavi test frame?

at Object.eq (src/wd-tests/src/all-tests.js:359:10)
at Context. (src/wd-tests/src/basic-test.js:11:10)
at Generator.next ()
at pump (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:3221:25)
at callNext (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:3207:7)
at ManagedPromise.invokeCallback_ (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:1366:14)
at TaskQueue.execute_ (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:2970:14)
at TaskQueue.executeNext_ (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:2953:27)
at asyncRun (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:2813:27)
at /home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:676:7
at process._tickCallback (internal/process/next_tick.js:103:7)
From: Task: basic test should get the title of test frame page
at Context.ret (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/testing/index.js:185:10)
at /home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/testing/index.js:104:5
at ManagedPromise.invokeCallback_ (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:1366:14)
at TaskQueue.execute_ (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:2970:14)
at TaskQueue.executeNext_ (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:2953:27)
at asyncRun (/home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:2813:27)
at /home/akahuku/.nvm/versions/node/v7.2.1/lib/node_modules/selenium-webdriver/lib/promise.js:676:7
at process._tickCallback (internal/process/next_tick.js:103:7)

見てのとおり殆どがスタックトレースの情報なのだ。こんなのいらないよ…。いや役に立つときはあるにはあるだろうけど、少なくとも mocha や selenium 内部のスタックトレースは普通はいらない。

そんなわけで、アサートを単に assert.equal() を呼ぶのではなく、

try {
assert.equal(actual, expected);
}
catch (ex) {
ex.stack = ex.stack.replace(/* cute regexp */, '');
throw ex;
}

なんてコードが考えられる。これはこれですごく嫌らしいコードなのだが(stack プロパティが書き換えられていいの?)、これでやってみてもスタックトレースは空にならない。上記の [cci]From: Task:[/cci] で始まる行以降の部分は、すでに selenium が stack に追記済みなのである。なので、stack を操作して再度 throw してもそれを selenium がまたいじるので、スタックトレースは空にならない。selenium にそのへんを何とかするオプションがあるのかはまだ調べてない。

ということで、とりあえずのワークアラウンドは
mocha --timeout=60000 --reporter=almost-min src/wd-tests/src/all-tests.js | sed -e '/^\\s*at\\s*/d' -e '/^\\s*From:\\s*Task:/d'
てな感じに、すべてのテストが完了した後に sed で削ぎ落とすことくらいしか思いつかない。これだと、mocha ならではの色とりどりのテスト結果ではなくなってしまうが、まあ個人的にはあれはちょっと華美すぎだと思うので、これはこれでいいかな…。

Testing with selenium javascript binding

wasaviの機能テストは今javaで書いているのだがjavaでなければならない理由は別にない。なぜjavaを選択したのかといえば、かつてはwasaviのビルドにantを使っていたのでそのへんの相性だとか、Seleniumのコード例として割とjavaが多く検索に引っかかるとか、公式のAPIリファレンスがjavadocだったからとか、その程度の理由だ。

しかし機能テストの個数が増えてくるとjavaだと困ったことにコンパイルにもそれなりに時間がかかってくるわけでなかなかストレスフルだ。それ以前にテストが全体的に遅い。ブラウザを起動する速度すら遅い。これを期に、スクリプト言語に移行したい。wasavi場合それ自体をJavascriptで書いているのだから、Javascriptに移行するのが自然だ。なによりJavascriptへのバインディングはSeleniumが公式でメンテしているのであんしんあんぜんということだ。ちなみに実はビルドの際に呼び出されるちまちましたスクリプト群も以前はRubyで書いていたのだが全部Javascriptに書きなおした。

ということでJavascriptによるテストコードの基盤を書いているのだが。基盤とはなんのこっちゃというと、各々の記述されたテストはページ上のtextarea、あるいは時にはdiv要素に対してwasaviが起動していることを前提としている。なのでテストの前段階でCtrl+Enterを送出してwasaviを起動させ、実際に起動したことを確認するコード、後段階でwasaviを終了させるコードを挟む必要があるのだ。そういったことをするために、基本的には


@test
public void testFoo () {
startWasavi();
// test body
;
closeWasavi();
}

なんてふうにテスト自体の先頭の末尾に何がしかの処理を挟むことになる。しかしこれはめんどくさいわけで、もうちょっと賢く特定の処理を割りこませたい。

となると次の案としては当然setUp()とtearDown()を定義してそこでwasaviを開いたり閉じたりすればよいのである。ここまでは実に普通だ。めんどくさいのはここからだ。

テストの中には、textarea要素ではなくcontenteditableなdiv要素とか、あるいはセクション・パラグラフ・センテンスをテストするために予めそのための初期本文が必要であるとか、初期化のタイプにもいくつかのバリエーションがある。そのへんもテスト本体に手を入れることなく1箇所で面倒を見たい。たとえばセクションに対するテストであればtestSectionなんとか、ってメソッド名なので、それを利用すればいい。あるいはアノテーションでもまあいい。しかし…困ったことにsetUp()にはそういったテスト自体のメタ情報は渡されないのであった。そのかわり、JUnitの場合TestWatcherというクラスがあってテストスイートの進行具合を観測することができるので、これを使う。

さて、これがJUnitからmochaへ移行するとどうなるか。setUp()とtearDown()は、beforeEach()とafterEach()という同機能が用意されているので単にそれを使えばいい。しかしやはり困ったことにこれらのメソッドにもテスト自体のメタ情報は渡されないのであった。というわけでTestWatcherの代替品を探さないといけないのだが、ない。

無理やり代替品を2つ考えてみると、まずReporterというものがありこれがテスト結果を表示する。これが内包するリスナはテストランナーから送出される各種イベントを受信して、その中にはテストのメタ情報が含まれる。なのでそれを使ってテストスイートへリダイレクトする。これのconsは好きなReporterを使えなくなるという点。

もうひとつは、テストの定義にit()を使うのでそれをラップして、

var testNames = [];
var originalIt = it;
it = function (should, fn) {
testName.push(should);
return originalIt.apply(undefined, arguments);
};

あとは beforeEach()内で[cci]testNames[/cci]から順々に表明を取り出せばそれは個々のテストを区別できる。これのconsは、必ずしもテストがit()の呼び出し順で実行されるとは限らないという点。

というわけでどちらもイマイチな点がある。うーむ。

 * * *

もうひとつ。JavascriptのSeleniumバインディングは、ほぼすべてのAPIがPromiseを返す仕様なのだ。だから、Javaであれば同期的に

WebElement el = driver.findElement(By.id("foobar"));
el.click();

などと何も考えずに書いていたコードは

driver
.findElement(By.id('foobar'))
.then(el => {el.click()});

というような感じになる。やることがシーケンシャルなのであれば.then()の羅列でいいのだがしかし分岐やループが入ってくるととたんに面倒くさくなってくる。それで、WebDriver.promise オブジェクトが用意されていてこれがジェネレータを引数に取り、ジェネレータがyieldしなくなるまで呼び出し続け、最後にresolve()するというナイスな関数consume()を持っているので

WebDriver.promise.consume(function*() {
var el = yield driver.findElement(By.id('foobar'));
yield el.click();
});

てな具合に同期的っぽく書ける。というかこれを使わないととてもじゃないけど書いてられない。気をつけないといけないことが一つあり、WebDriver.promiseはdeprecateである。なので将来的にはこれはasync/await版にしないといけない。