JavaScript のテスト
書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。
最小のテスト
本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。
isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。
// assert
function assert(actual, expected) {
console.log('.');
console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected);
}
function TestSum() {
assert(1+2, 3);
}
// exec
TestSum();
あとは普通にこのスクリプトを node/io で実行するか、ブラウザに読ませるだけでいい。
ちょっとしたスクリプトを書くだけでオーバーキルなものを選ぶ必要は、本来は無い。
目的はテストであって、テストモジュールを使う事ではない。
そこで手が止まるくらいなら、これで十分。
実例: [https://github.com/Jxck/URLSearchParams/blob/master/test/test.js]
assert
個人的には assert は strictEqual だけあれば良いと思っているが、まあある程度便利メソッドがあっても良いとは思う。
node/io であれば assert が標準にあるのでそれを使う。
これを ブラウザ用に移植 したものがあるので、ブラウザではそれを使う。
var assert = assert || require('assert');
function TestSum() {
assert.strictEqual(sum(1, 2), 3);
assert.strictEqual(sum(0, 0), 0);
}
TestSum();
テスティングフレームワーク
もっと大きくなる場合は、適切なフレームワークを入れる。広く使われているものを使う方がいい。
なによりも非同期テストが入ってくると上の方法は足りてない。
テストや各種レポータや、オプションが多い CLI、蓄積されたノウハウやという意味で個人的には mocha を勧める。他のでもいいけど、少なくとも今から QUnit を積極的に選ぶ理由は無いと思う。
mocha はテストの構造に関する責務を持つが、 assertion は持たない。
そこで expect や chai など色々あるが、個人的には上述の標準 assert で十分だと思う。
以降紹介するツールも、 mocha との連携方法が結構紹介されているという点も、長いものに巻かれるメリットと言える。
Github に置いた OSS なら travis ci に繋ぐという話は今更しないで良さそう。
ブラウザテスト
ブラウザを、しかも複数のブラウザをいちいち起動したり、更新するのは面倒なので、そこはツールでやる。おすすめは karma だが、まだ他にも選択肢があって個人的にも揺れている。
Github に置いた OSS なら browserstack とかもありだと思う。
カバレッジ
カバレッジをとるかどうかは別として、とる場合は karma なら簡単に istanbul が使える。
結果を html で吐くと、細かく解析される。
Github に置いた OSS なら coveralls もありっぽいが個人的には使ってない。
規模に合わせる
この辺まで来るともうビルドタスクとかも入り、設定ファイルも増えてきてるはず。
テスト自体が、複数環境や非同期やプリプロセスなどが入ってそもそも面倒なのが原因で、それらを個々のツールで解決するため、そうなるのは避けられない。
ただ、テスト自体やそれを実行する複雑な環境の構築が価値を生む訳ではないので、そこで手が止まるくらいなら、小さく始めてでもコードを書いた方が何倍も価値を生む。
一方で、コードベースが大きくなった時にきちんと基盤が整っていないと、割とすぐに破綻するのも事実。
今書いているコードの規模をきちんと把握し、適切な構成にするコストは、破綻してからなんとかするコストより絶対安いので、それをふまえて少しづつ手を入れて行くのが大切だと思う。
もしくは、どんな小さいプロジェクトでもすぐに完璧な環境が導入できるように、自分のスケルトンを用意しておいて、常に磨いておくという手もある。そういう人に、このエントリはいらないだろう。