});JavaScriptでもテストを書こう@ITの読者の方たちのほとんどは、どのような言語を主に利用しているのかなどの違いはあるにせよ、日常的にプログラムを書いている方たちが多いかと思います。アプリケーションを作る、ライブラリを作成する、オープンソースプロジェクトに貢献するなど、皆さんがプログラムを書く場面はそれぞれいくつかあるはずです。それらプログラムを書く場面に共通して大切な習慣の1つとして、「作成するプログラムに対しては必ずテストコードを書く」ことがあるのは、誰にでも同意してもらえることでしょう。1回だけで使い切り、もう2度と使わないようなプログラム以外、通常あらゆるプログラムは最初に作成されてから、さまざまな修正や変更が加えられます。そのような修正・変更を行うのは、そのプログラムを最初に作った人とは限りません。プログラムの仕様に従って、どんな動作をするように書かれたものなのかを保証するテストコードがなければ、「常に動作する状態を保ちながら、誰がどんなタイミングで、そのプログラムに変更を加えても大丈夫」という環境を作ることは困難です。「テストコードが書きやすいプログラムか」、さらには「常にテストコードが書きやすい状態にプログラムを保てているか」が、そのプログラムが良い構造・設計で作られているかを判断するための1つの指標にもなります。それぞれの処理が適切な大きさに分割され、その処理で何を実現しようとしているのかを的確にとらえて設計されていれば、テストコードを書くこと自体も容易なはずです。その他にも、テストコードを書くことの有用性・重要性については、皆さんいくつも思いつくのではないでしょうか?ここでは本題と外れますので、テストコードを書くということのみについて、さらに踏み込んでお話しすることは避けますが、たまには普段の自分たちのプログラミング、開発活動を思い返してみて、「ちゃんとテストコードを書く習慣ができているかなぁ?」「テストコードがちゃんと書ける良い設計のプログラムを書けているかなぁ?」ということを振り返ってみるのもいいかもしれません。JavaScriptで書かれた部分です。一口にJavaScriptといっても、最近ではその利用が多岐に渡っています。ここで少しだけその点について述べたうえで、今回の連載で扱う範囲をお話しします。書くまでもないことですが、ネットスケープ社で「LiveScript」として産声を上げた当初から、JavaScriptはWebブラウザ上で動作し、クライアントサイドでWebページに動的な要素や機能を追加するために使われてきました。一時期のWebブラウザ間の実装差異による互換性のなさが、ECMAScriptとして仕様が標準化されていく過程で徐々に解消されるようになってからは、容易に使えることもあって、利用が広まりました。クライアントサイドJavaScriptは、Ajax→jQuery→HTML5という大きな流れ「Ajax」という技術的な再発見がなされてからは、それがさらに加速しました。その利用の広がりに従って、便利でよくできたライブラリなども多数作成されるようになりました。皆さんがよく利用しているものだとjQueryなどは好例でしょう。kwoutさらに、今後のHTML5の利用を想定すると、JavaScript利用の主戦場の1つがクライアントサイドであることに変わりはないでしょう。kwoutサーバサイドもJavaScriptで一方で、例えば「node.js」を代表とするようなサーバサイドでのJavaScriptの利用も広がっています。Webブラウザ上でのJavaScriptの実行パフォーマンスを向上させるために改良が重ねられてきた実行エンジンが、今では単独でも利用できるような形で提供されています。node.jsでも利用されているグーグルの「v8」は良い例でしょう。kwoutエンジンが単独で利用できるような形で提供されるようになると、JavaScriptがもともと持っている言語的な特徴としての柔軟性もあって、単にWebページを動的にするのに留まらず、バックエンドの処理まで含めた実装への応用が始まりました。スマホ/タブレットのアプリもJavaScriptでまた、最近のもう1つのJavaScript利用の重要な流れとして、モバイルへの応用が広まりつつあることが挙げられます。スマートフォンやタブレットが普及するにつれ、本格的なマルチデバイス・マルチスクリーンの時代が到来しています。それらデバイスやプラットフォームの差異を吸収するクロスプラットフォームな開発技術が必要となってきています。Mobile」などのライブラリを使うことで、モバイル向けにJavaScriptの利用が進んできています。kwoutクライアントサイドJavaScriptはテスト環境が整ってきたさて、ざっと最近のJavaScript事情を概観したところで、今回の連載ではどの部分にフォーカスするかですが、やはりWebブラウザ上で動作する部分、クライアントサイドでのJavaScriptの実装に対するテストについてをまとめてみようと考えています。「なぜ、クライアントサイドなのか」には2つ理由があります。サーバサイドでの利用の広まりなど、やや事情が異なる面も出てきてはいても、先ほど述べた通り、WebアプリケーションにおけるJavaScriptの主な活躍の場がモバイルへの応用も含めたクライアントサイドであるという点が1つです。クライアントサイドのJavaScriptは、その動作にWebブラウザが必要で単純にテストコードを書いてテストをするという具合にはいきませんでした。最近のテスティングフレームワークの中には、その点を克服しつつ、クライアントサイドを含めたJavaScriptのテストを行いやすくするものが出てきているからというのが、もう1つの理由です。本連載では、いくつかのテストのためのフレームワークについて、特徴と実際の使い方をまとめます。今回は連載第1回目なので、JavaScriptのテストに関する概観とクライアントサイドのテストを行う場合の手法・テスティングフレームワークの種類、連載の中で扱うフレームワークの簡単な紹介を次項以降でお話しします。本連載では扱いませんが、もちろんサーバサイドJavaScriptのテストを行いやすくしてくれるテスティングフレームワークにもいくつか良いものがあります。ご存じな方も多いかもしれませんが、興味がある方はそちらも合わせて調べてみると、より良いJavaScriptライフが送れるはずです。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。