QUnit＋PhantomJSでJavaScriptのヘッドレスなテスト：フレームワークで実践！ JavaScriptテスト入門（3）（1/3 ページ）

しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載。今回は、xUnit系のテストフレームワークとして人気のQUnitの概要や使い方、PhantomJSと組み合わせたテスト方法を紹介

[朝香貴寛，TIS コーポレート本部 戦略技術センター]

ヘッドレスなJavaScriptテスト

　前回の「PhantomJSとJasmineで振る舞い駆動開発なJavaScriptテスト」では、PhantomJS＋Jasmineという組み合わせでJavaScriptテストをヘッドレスで実行する方法を紹介しました。今回は「QUnit」というJavaScriptテストフレームワークでヘッドレスなテスト環境を構築するする方法を紹介します。

　Jasmineはスペックを記述していくテストフレームワークでしたが、QUnitはその名前の通りxUnit系のテストフレームワークです。

JavaScript（jQuery）用テストフレームワーク「QUnit」とは

　テストフレームワークと言えば、多くの人がxUnit系フレームワークを思い浮かべるのではないでしょうか。xUnit系フレームワークはあらゆるプログラミング言語に存在し、テストフレームワークの定番となっています。JavaScriptも例に漏れず、「jsUnitTest」「QUnit」というテストフレームワークがあります。

　QUnitは、もともとjQuery用テストフレームワークでしたが、現在はjQueryに依存していないため、jQueryと関係なくJavaScriptのテストを実行できるようになっています。

QUnit via kwout

　以下は、主な特徴です。

• xUnit系のフォーマットに近い書式
• jQueryでの実績
• 外部ツールとの連携が容易
• アドオンによる拡張性

　このような特徴から、他のプログラミング言語でxUnit系テストフレームワークを利用したことのある方は受け入れやすいかと思います。

　また、jQueryでも利用されていることから、JavaScriptのテストに必要な機能がそろっているとうかがえますし、信頼を持って利用できるのではないでしょうか。

　その他にも、テスト実行結果を取得できるAPIなどがあり、今回のように外部ツールと連携しやすくなっています。

QUnitのテストの書き方

　QUnitのテストコードは以下のようなフォーマットで記述します。

module("sync");
test("syncFuncTest", 1, function(){
    equal("hello, world!", syncFunc(), "return to expected data");
});
module("async");
test("asyncFuncTest", function(){
    expect(2);
    stop();
    asyncFunc(function(message){
        start();
        ok(true, "call to callback function");
        equal("hello, world!", message, "return to expected data");
    });
});

　テストは基本的にtest関数の第1引数にテスト名を指定し、最後の引数に指定する関数内でassertionを記述していきます。第2引数の数字は実行が期待されるassert数で、2つ目のテストのように省略したり、expect関数で指定したりすることが可能です。

　また、asyncFunc関数のような非同期処理のテストを行う場合は、テストランナーをstart関数が呼ばれるまで停止するstop関数と、テストランナーを再開するstart関数を用いることで実現できます。

　その他にも、「asyncTest」関数が用意されていますが、こちらはstop関数を省略して記述できます。

　1行目のmodule関数は以降の行にmoduleが指定されるまでの間のテストをグループ化できます。moduleは記述しなくてもテストを実行可能ですが、指定しておくことでモジュール単位でのテスト実行が可能です。

QUnitの主なアサーション

　QUnitでは以下のassertionが用意されています。

ok(state, message)

• 第1引数の値をテストするassert
• ok(true, "message")のような書き方で、コールバック関数の中に記述し、そのコールバックが呼ばれることをテストするなどにもよく用いられている
• 第1引数が、[false, 0, NaN, "", null, undefined]であれば、testがfailする（空配列はtrueになる）

equal(actual, expected, message), notEqual(actual, expected, message)

• actualとexpectedを比較し、等しくなければtestがfailする
• ==での比較であり、typeまでテストする場合は、strictEqual()を用いる

deepEqual(actual, expected, message), notDeepEqual(actual, expected, message)

• actualとexpectedに与えられた値の内容を再帰的に比較し、等しくなければtestがfailする
• プリミティブ型、配列、オブジェクト、正規表現、Date型、関数の比較が可能

strictEqual(actual, expected, message), notStrictEqual(actual, expected, message)

• actualとexpectedを比較し、等しくなければtestがfailする
• ===で比較するため、値の型も等しくなければfailする

throw(block, expected, message)

• block処理の中でerrorがthrowされることをテスト
• expectedにはthrowされるErrorオブジェクトを指定

その他

　上記の例には含めていないですが、もちろんsetUp関数やtearDown関数も用意されています。

　このように、JUnitのassertionよりは簡略化されていますが、JUnitを使ったことがある人には割となじみやすいのではないでしょうか。

　一通りのテストの記述方法は「QUnit API Documentation」「Cookbook | QUnit」にサンプルがあります。

　また、実際のプロダクトで使われているテストコードとして、jQueryのテストコードを参考にできますので、JUnitを触ったことがない人でもとっつきやすいかと思います。