JavaScriptのテストについて本気出して考えてみた(2) - 愛と勇気と缶ビール
前回からの続きで。 DOMエミュレーションの戦略 一方で、本物のブラウザを使わずに何らかのJavaScript実行環境でDOMをエミュレートして、その上でテストを走らせよう、という戦略もある。 この分野の大御所はEnv.js(http://www.envjs.com/)ということになっているのだけど、Env.jsのイヤンなところは導入がめんどくさい所である。何がめんどくさいって、antでビルドしなくちゃいけない。テストのためにどの程度の環境構築コストをかけられるかは状況において違うだろうが、例えばJSをメインでやっているエンジニアが「ちょっとテスト環境整えたい」っていう時にantから入れて頑張るだろうか？Javaの経験や、こういうビルドツールの導入/利用の流れに慣れている人だと全然問題ないレベルなんだけど。 というわけで、Env.jsは結構力を入れて開発されたものではあるのだろうけど、僕に
Test::QUnit - mozrepl経由でコマンドラインからJavaScriptのテストを実行する - 愛と勇気と缶ビール
マクラ - JavaScriptのテストについて テストのないコードはコードではなく、テストを書かないプログラマはプログラマではなく、テスティングフレームワークのない言語は言語と呼ぶに値しない。と以上のような偉そうなことを言う資格は全くないし狂信的でもない僕ですが、少なくともまともに動くコードであることを証明するために、人並みにはテストを書きます。 それでまあ、最近JavaScriptばかり書いてるのですが、JavaScriptのテスティングフレームワークって大体以下のようなものに分かれると思っています。 ブラウザ上で動かすことを前提としたもの(JsUnit, QUnitなど) RhinoやSpiderMonkeyなど、ブラウザから独立したJavaScriptエンジンで実行することを前提としたもの(JsUnit, QUnit-TAPなど) 2. に加え、env.js(http://www.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
