367
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

posted at

updated at

小さく始める JavaScript のテスト

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

以降紹介するツールも、 mocha との連携方法が結構紹介されているという点も、長いものに巻かれるメリットと言える。

Github に置いた OSS なら travis ci に繋ぐという話は今更しないで良さそう。

ブラウザテスト

ブラウザを、しかも複数のブラウザをいちいち起動したり、更新するのは面倒なので、そこはツールでやる。おすすめは karma だが、まだ他にも選択肢があって個人的にも揺れている。

karma

Github に置いた OSS なら browserstack とかもありだと思う。

カバレッジ

カバレッジをとるかどうかは別として、とる場合は karma なら簡単に istanbul が使える。
結果を html で吐くと、細かく解析される。

karma-cverage

Github に置いた OSS なら coveralls もありっぽいが個人的には使ってない。

規模に合わせる

この辺まで来るともうビルドタスクとかも入り、設定ファイルも増えてきてるはず。
テスト自体が、複数環境や非同期やプリプロセスなどが入ってそもそも面倒なのが原因で、それらを個々のツールで解決するため、そうなるのは避けられない。

ただ、テスト自体やそれを実行する複雑な環境の構築が価値を生む訳ではないので、そこで手が止まるくらいなら、小さく始めてでもコードを書いた方が何倍も価値を生む。

一方で、コードベースが大きくなった時にきちんと基盤が整っていないと、割とすぐに破綻するのも事実。

今書いているコードの規模をきちんと把握し、適切な構成にするコストは、破綻してからなんとかするコストより絶対安いので、それをふまえて少しづつ手を入れて行くのが大切だと思う。

もしくは、どんな小さいプロジェクトでもすぐに完璧な環境が導入できるように、自分のスケルトンを用意しておいて、常に磨いておくという手もある。そういう人に、このエントリはいらないだろう。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
367
Help us understand the problem. What are the problem?