フロントエンド開発Blog

オレには鈍器がある

JSテスト , JavaScript , browserify , html2js , karma , mocha , power-assert

JavaScriptのテスト、ちょっと前までは「え、サーバサイドJavaScriptの話ですよね?クライアントJavaScriptならやっぱ実機確認に勝る方法はありません!」と思ってて食いついてませんでした。まぁ今でもUIテストとなると実機確認が必要だと思うんですが、「個々の関数が想定通りの動きをするかどうか」「例外処理は考えられているか」とか、システムテスト工程的にいうところのユニットテストがあっても良いと思い直して導入してみました。ただ、ここらへん分かりにくいというか、テストツールだけでもたくさんツールがありますし「何が最強」とは言い切れないのが正直なところだと思います。

ひとまず、今熱そうなmochaとkarmaあたりを使いたいな~と軽い気持ちで始めたら導入にどつぼったのでメモ。

ひとまずテンプレート作りました。

サンプルJSを対象にテスト実行がすぐできます。コマンドラインで以下2行を入力するだけで動くはずです。

npm install
karma start

Chromeが立ち上がり、CLIにはテスト結果が表示されます。さらにChrome画面上に表示されているDEBUGというボタンを押すとGUIでテスト結果が表示されます(内容はCLIと同じですが見やすい)

結構つまづいた

アサーションライブラリにはエラーしたときのエラー表示がめちゃめちゃ分かりやすいと評判のpower-assertを使ってます。このpower-assertをブラウザ表示モードで使うためにはbrowserifyで変換しないといけなかったり、結構躓きやすいようで、実際に自分も躓きました。どうもちまたに溢れる情報では「karma-browserifast」というpackageを使え!と紹介されてますが私の環境では上手く動きませんでした。それで代わりに「karma-browserify」を使ったら上手く動きました。

更にDOMを必要とするフロントエンド開発におけるJavaScriptのテストを想定するなら、やはりHTMLデータをテスト内で使用したい。ということでhtml2jsを使ってHTMLをwindow.__html__["HTMLファイル名"]オブジェクトに変換する方法を取りました。これも、karma-browserifastを使うと何故かpower-assertらしからぬ「undefined is not function」などと訳の分からないことを言い出して正しく動作しませんでした。

何故導入で躓きやすいのか

調べてみると同じくテスト機構の導入に躓く人が多いようです。というのもnpmパッケージ自体の新陳代謝が激しく、去年はそれで動いたけど今年はもう動かない、みたいなことになりがちなのかなと思いました。package.jsonを公開してくれてて導入時のバージョンやだいたいの日付が分かるようにしてくださってる情報サイトは少ないですが、流れの速い分野ならpackage.jsonを公開しちゃうのもありかなと思いました。

大変だけどやってよかった

結構導入に手間取ってしまいましたが、これならDOMと密なJSだろうが、HTML何それおいしいの?みたいなごりごりのバックエンドJSだろうが、同じkarma環境下でのテストができそうです。ブラウザで結果が見られるってのもグラフィカルで目に優しいですね。CLIにも出力されるので、まぁかたくなにGUI見たくない人のニーズもくみ取れると思います。

テストの自動化はGulpやGruntでタスクを作る人と、今回のようにKarmaを使う人に大きく分かれるようですが、正直どっちでもいいかなと思います(笑)好みの問題ですし・・・得られる結果は同じですからね。

Gulpで統一しようかな、とも考えたのですが、今後やりたいことが増えた時のことを考えてテスト実行環境としての振る舞いが期待できるKarmaの導入に踏み切りました。

ページトップへ

関連ページ

ページトップへ