Habit modulation #2

というわけでテストを書く。

テストは mocha に実行させる。一方、桃は esm の文法に基づいてモジュールを分けてある。ここで問題が出てくる。ググればたくさんその手の話が出てくるが、要するに mocha、ひいては node.js が今現在 cjs と esm の過渡期にあって、まだあんまり esm の対応が行き届いていない。

mocha においても、import/export を使ったソースを渡してもエラーになる。その辺をどうするかはまさに議論中のようだ。

で、いくつかのワークアラウンドが考えられて:

  • ブラウザ上でテストを実行する: cjs と esm の混乱はあくまで node.js の中の話である。ブラウザを起動してその上でテストを実行すれば普通に esm のコードがテスト対象になる、はず
  • esm のコードを babel でトランスパイルした上でそれをテストする
  • モジュールをダイナミックロードする

前2者はワークアラウンドにしては大掛かりになるので、最後の奴で行ってみよう。

const assert = require('assert'); let testfunc1, testfunc2; before(() => import('./path/to/module').then(module => { ({testfunc1, testfunc2} = module); }); describe('test', () => { it('works', () => { // test code with testfunc[12] }); });

どうでもいいが最近のこの wordpress のエディタが使いにくい。

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版にしないといけない。