どんなプログラミング言語やプラットフォームでも、良く考えられたユニットテストのセットを持つことは、保守可能なコードを納品するために、一般的に認められたプラクティスである。これはJavaScriptのような動的言語には特に当てはまり、現在、いくつものフレームワークとライブラリがあり、チームはその中から選ぶことができる。
InfoQは主要なJavaScriptのユニットテスティングフレームワークの作成者達に、彼らのプロジェクトや彼らが開発者に提供しているものについて、質問した。
参加者は、
- QUnitのJorn Zaefferer氏
- JasmineのDavis Frank氏
- JarvisのTommy Montgomery氏
- jfUnitのFelipe Nascimento de Moura氏
あなた方のプロジェクトは実際に何をしてますか?他のJavaScriptテスティングフレームワークとどう違うのですか?
Jörn Zaefferer : QunitはJavaScriptのテスティングフレームワークです。ブラウザ中で動くユニットテストとして使われるときに、一番の価値を提供します。 jQuery傘下のプロジェクトですが、 jQueryに依存してませんし、ブラウザが提供するDOM部分にさえ依存してません。ですから、QUnitを node.js や Rhinoで走らせることもできます。 QUnitは、走らせるのが非常に簡単で、htmlページに2つのファイルを含むだけでいいのです。インストールとかビルドする必要はありません。最小限の機能テストスイートは、たった11行のコードでできたhtmlファイルです。
Davis Frank : Jasmine は、JavaScriptのテスティングフレームワークで、テスト駆動のJavaScriptコードに Behavior-Driven Developmentスタイルを持ち込むことを狙っています。どう違うか、といいますと、我々が目指しているのはBDD(標準のTDDに対して)であり、我々は開発者がxUnitフレームワークよりも、もっと表現が豊かで、良く練られたコードを書くのを助けることです。できるだけ依存性を持たないように努力しました。なので Jasmine仕様をNode.JS やブラウザベースのアプリケーション、あるいはモバイルアプリケーション用に書くことができます。
Tommy Montgomery: JarvisはJavaScriptのテスティングフレームワークで、.NETスタック向けのユニットテスティング フレームワークである、NUnitのAPIをベースにしています。他のフレームワークと違うところは、スタック トレースダンプ、文字列の比較で色付けした差分表示、読みやすいAPIです。
Felipe Nascimento: jfUnitの主な特徴は、そのロードのされ方と、書かれ方です。ユニットテストをより少ないタイピングで書けますし、それをあなたの開発環境から走らせることができます。お望みであれば、コンソールからでも走らせることができます。
InfoQ: アーキテクチャについて少々詳しく説明していただけませんか? 主要なコンポーネントは何ですか?
Jörn Zaefferer: QUnit APIは非常に素直で、テストメソッドを呼び、名前とコールバックを渡し、それから様々なアサーションメソッドを使って、そのコールバックの中に実際のテストを実装します。その周りに、QUnitはテストスイートをまとめるのにいくつものオプションを提供しています。例えば、コールバックのセットアップやティアダウンができるモジュールなどです。内部的には、これらのコールはキューにマップされます。環境によって、QUnitは window.loadや他のイベント(あるいはユーザーによってトリガーされた時)によって、キューからテストの実行を始めます。テストが非同期で走る必要があることを表明したら、キューの実行は止められ、それが終わったことをテストが表明したら、再開されます。キューの実行順は可変です。デフォルトで、オプションのフィーチャが前回のテスト結果をベースにテスト実行順序を変更します。それでも結果をちゃんと順番に表示します。成功したテストを隠すオプションによって、以前失敗したテストに戻ることができ、その失敗したテストが成功するか、まだ失敗するかを直ちに検証できます。全スィートが走るのを待つ必要がありません。QUnitのフィーチャのほとんどは、QUnitベースのテストスイートを使ってテストされています。
Davis Frank:我々は単純にすることを心がけています。 Jasmineの中核は、1つのJavaScriptファイルで、もし含まれていると、スィート、ネストしたスィート、仕様を展開するDSLを提供します。DSLは仕様に関連した関数のツリーを作り上げ、それらを実行します。この部分は非常に単純です。
この上にレイヤーがあり、異なった環境で結果を報告できたり、ソースファイルや仕様ファイルの管理をより簡単にできるのです。我々は Ruby on Railsやどのようなwebフレームワークとも協働開発できます。ある人達は、Node.jsプロジェクトにテスト的に取り組んでます。実際、JavaScriptが走るところなら、Jasmine は走るはずです。そうでないなら、我々はその環境で走るようにする必要があります。
Tommy Montgomery: 他のXUnitフレームワークのようにJarvisは制約ベースです。1つ1つのアサーションは隠れたところで制約オブジェクトを生成し、それが期待値に対して実際の値を評価します。例えば、Assert.that("foo", Is.equalTo("bar"))のようなものを走らせると、左辺の"foo" と右辺の"bar" とで等価かどうか比較します。このAPI(これもNUnitから借りたものですが)は非常単純で、直感的に読みやすいです。このことはユニットテスティングの重要な部分だと考えています。ユーザーレベルでの主要なコンポーネントはAssertオブジェクト、Isオブジェクト、そしてランナーです。Assertオブジェクトは2,3の関数を公開して、値でアサーションを発生できるようにし、一方、IsオブジェクトはJarvisの制約ベースのアーキテクチャを公開します。テストを走らせるには、Jarvis.run()を呼んで、テスト関数に渡します。Jarvisのテスト結果のレポート方法は設定可能で、2つのレポーターが付いています。1つはコンソール(例えば FirefoxのFirebug)用で、もう1つはHTMLを生成します。
Felipe Nascimento: jfUnitと呼ばれるグローバルな要素を持つ構造を使っていて、その中にテストを追加したり、削除したりできます。テストを記述している間は、実行されません。しかしこのメインオブジェクトに実行するように言えば、コンソールからでもブラウザのアドレスバーからでも実行できます。お薦めしたいのは、それ(ライブラリ自身とテスト用のスクリプト)を自動的に開発とテスト環境にロードして、出荷の時にはそれらを削除することです。そうすればお望みの時にテストを実行でき、その結果を直ちに画面に表示できます。
InfoQ: 開発者が皆さんのフレームワークを使い始める最もいい方法は何ですか?典型的なワークフローを言ってください。
Jörn Zaefferer: Script JunkieにQUnitを紹介する良い記事があり、初歩的な紹介、ほとんどのQUnit API、QUnitでテスト駆動開発をずっと効率的にできるようにする、テスト実行環境の高度なフィーチャを扱っています。
Davis Frank: たくさんの様々なスクリーンキャストやチュートリアルが色々なところにあります。 Railscastsのものは非常に素晴らしいです。 PeepCodeのCoffeeScript キャストもいいです。内容は CoffeeScriptについてですが、 Geoffrey氏が Jasmineでテスト駆動の流れを非常に良く説明しています。
Tommy Montgomery: 開発者がJarvisを始める一番いい方法は webサイトに行き、サンプルコードを見て、サイトでテストを走らせて、テストがどのようなもので、テスト結果レポートがどんなものであるか、正確に理解できます。Jarvis自身はJarvisを使ってテストされています。そのテスト結果は ここで見ることができます。テストを書く典型的なワークフローは開発者に依存します。Jarvisはそれについて、何の想定もしていません。メインのテスト実行モジュールはHTMLベースなので、ブラウザを開いておくことが必要です。私の個人的なワークフローは、コードを書き、テスト書いて、ブラウザをリフレッシュして、テスト結果を見ます。この繰り返しです。
Felipe Nascimento: もっと詳しい情報はここにあります。基本的に、開発者はライブラリをロードして、次にjfUnit オブジェクト設定をテストで使用したい数だけ使う必要があります。これが一旦上手くいけば、jfUnit.run()コマンドを実行して、その結果を見ます。またパラメータや環境変数の設定(オプションで)に、jfUnit.config({...}) を使えます。注意してほしいことが1つだけあります。それは、レポートの作成に、ドキュメントボディ要素を使っていることです。そのために、ページは、少なくとも1つのボディ要素をすでにレンダリングしておく必要があります。
InfoQ: 将来どのようなフィーチャを実装したいですか?またJavaScriptのテスティング フレームワークは全体として、どのように進化すると思いますか?
Jörn Zaefferer: 一番優先度の高いのは例えば node.js内で、より良いコマンドラインの統合です。既にそれは動いているのですが、今のところメインの qunit.jsファイルにない追加のスクリプトが必要です。それが統合されれば、npmを介してQUnitを公開することになります。他にやりたいのは既存のフィーチャの改善です。結局、PavlovのようなBDDラッパーを取り入れるかもしれません。それまでQUnitを使いたいがBDDの方が好きな人は、QUnitに加えてPavlovを使うのがいいです。コードフィーチャではありませんが、qunitjs.comが今年中に立ち上がります。
Davis Frank:我々は Pivotal Trackerに公開しているバッグログがあり、これからのリリースで何が優先度の高いものかを誰でも見れます。コミュニティから意見を歓迎してますが、我々は確かに選り好みをします。我々はJasmineを小さく、本質的なものに留めておきたいです。自分の修正やフィーチャを単純にして、自分の開発に含む仕様を確認してください。結局Jasmineはテストフレームワークです。あなたのテストフレームワークにコントリビュートしてみてください。
Tommy Montgomery: 今私はサーバー側のテストをサポートする nodejsを開発しています。今考えている他のフィーチャには、antタスクとコマンドライン実行があります。JavaScriptテスティングフレームワークは(大抵の場合)ブラウザを走らせておく必要のあることが、非常に障害になってました。これを受けて、ユーザーがブラウザーを簡単に起動できるようにすることが、JavaScriptユニットテスティングフレームワークにも必須になります。私はまた、JavaScriptユニットテスティングフレームワークがサーバー側のテストとクライアント側のテストの溝を埋めるのが得意になってきた、と思います。
Felipe Nascimento: 私はJavaScriptが大好きで、世界中の多くの開発者がこの言語を使うと信じています。私は物事をJavaScript、新しいツールや技術を使って、上手くやるのが好きです。私はBrazilJS(ブラジルのJavaScript カンファレンス)のメンバーの一人です。JavaScriptの将来は非常に素晴らしいと思っています。私は本当に新しいフィーチャを作って、このユニットテストツールを進化させ、もっと簡単な方法でAjaxコールを処理したり、ユーザーがずっと簡単にグラフィック インターフェースそのものをテストするスクリプトを書けるようにしたいです。例えばフォームを埋めたり、要素をサブミットしたり、ボタンをクリック(こういうことはできますが、書くのはちょっと難しいです)のようなことを簡単に書けるようにしたいです。またここで言いたいのは、もし読者が開発者でこのツールにコントリビュートしたいと思うなら、気軽に私に連絡ください。そして批評、アイデア、提案、バグレポート、コードを送ってください。どうすればいいかは、 私のgithubアカウントにあるプロジェクトに従うのがいいです。
パネリストについて
Jörn Zaefferer はフリーランスのweb開発者、コンサルタント、トレーナー、ドイツの Cologneに住在し、jQueryのテストスィートをJavaScriptのユニットテスティングフレームワークである、QUnitに発展させ、メンテしている。彼は幾つも人気のあるプラグインを作成した。jQueryのUI開発リーダーとして、新しいプラグイン、ウィジェット、ユーティリティの開発に焦点を当てている。
Davis Frank はソフトウェアエンジニア、父親、野球のファンで、北カルフォルニアに住んでいる。日中は、Pivotal Labs, Inc. のソフトウェアエンジニアでマネージャであり、顧客のためにコーディングしている。残りの時間は、子供に本を読み、妻を笑わせ、きた人にはフランクステーキを焼いてあげている。確実に家では、およそ99.9%はインターネットが接続している。
Tommy Montgomery は専攻が数学、副専攻がコンピュータサイエンスでカレッジを卒業した。2007年に San Diegoに移って、.NETの開発をした。それ以来LAMP関係のプロジェクトで主に働いてきたが、昨年あたりからもっと.NETに深く関わった。プログラミングで興味があるのは、PHP, C#,JavaScript。最近のプロジェクトでは Sunlight、クライアン側のシンタックス ハイライター、Jarvis、Butterfly、.NET とJavaScriptにおけるマークアップからHTMLへの変換ソフトである。
Felipe Nascimento de Moura はブラジルのシニア開発者で、システムアナリストである。約7年間、web開発に携わっており、WebMind.org, PHPDevBar、jfUnitのようないくつかのオープンソースプロジェクトの生みの親である。 BrazilJS、ブラジルJavaScriptカンファレンスのまとめ役の1人でもある。 JavaScript や ユニットテスティングについてもっと面白い記事が読みたければ、このInfoQにある。