なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
mocha と Jenkins で Node.js の CI 環境を構築する - hakobera's blog
最近、mocha をつかってテストを書くのが楽しくなってきました。でも、テストの数が増えてくるとローカルでの実行だけでなく、CI 環境が欲しくなりますよね。github にあげられるようなプロジェクトだったら、Travis CI も良いですが、実際に仕事で使うとなると、既存の Jenkins と組み合わせてやる必要ができてきたので、実際にやってみました。 基本的な手順は以下の通りです。 mocha でテスト結果を TAP 形式でファイルに出力する 出力したファイルを Jenkins の TAP Plugin に読み込ませる 簡単ですね。 実際にやってみた というわけで、以下のような最小構成で試してみます。 myapp |- lib | |- calc.js | |- test | |- calc.test.js | |- package.jsonここには書いていませんが、実際は git で
node.js+QUnit+QUnit-TAP+ant+JenkinsでJavaScriptのCI
2004 01 02 03 04 05 06 07 08 09 2004年9月：1エントリ 10 2004年10月：1エントリ 11 2004年11月：1エントリ 12 2004年12月：1エントリ 2005 01 02 03 04 2005年4月：13エントリ 05 2005年5月：18エントリ 06 2005年6月：28エントリ 07 2005年7月：42エントリ 08 2005年8月：39エントリ 09 2005年9月：41エントリ 10 2005年10月：22エントリ 11 2005年11月：20エントリ 12 2005年12月：35エントリ 2006 01 2006年1月：12エントリ 02 2006年2月：6エントリ 03 2006年3月：10エントリ 04 2006年4月：17エントリ 05 2006年5月：9エントリ 06 2006年6月：12エントリ 07 2006年7
Node.jsのテストフレームワークについて- WebService::Blog->new( user => ’hide_o_55’ )
Node.js のテストフレームワークは主要なものはここにありますが、どれがいいのか迷ったので試してみたもの、ドキュメントを読んで良さそうものについて印象を記録しておきます。 ちなみに、選出の基準は「ドキュメントが充実していること」です。 追記 ブコメで[twitter:@meso]さんが指摘されてますが、Tobiというブラウザの動作をエミュレーションするモジュールもあります。あと、nClosureもテスト機能をふくんでいるので追加しました。 更に追記(2012/2/23) この記事を書いた時点では存在しなかった以下のテストフレームワークを追加しました。 Mocha Buster.JS テストフレームワーク mocha(http://visionmedia.github.com/mocha/) Express等の作者であるTJが新たに開発したテストフレームワーク こちらの記事がよくまとまっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仮想パネル：最先端のJavaScriptユニットテスティング
