新卒入社3年目のエンジニア集団。それぞれが広告関連システム、ビデオ関連サービス、地図関連サービスの開発に関わる傍ら、Node.js、MongoDB、HTML5を組み合わせたブラウザ上で動作する社内用メッセンジャーツールを開発や、WebSocketを使った実験的地図サービスの開発をおこなっている。これらを実験場として、ブラウザの最新仕様やNode.jsのノウハウをヤフー社内に普及・啓蒙中。
本日行われた Shibuya.js の発表資料をアップしました。 さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 View more presentations from hotchpotch JS のテスティングフレームワークのおおざっぱな説明や JavaScript テストにおける問題、それについての解決方法の一つ、CUI でのテスト、Envjs、エンドツーエンドテストにおける JS / Ajax のテスト、終わりにちらっと Phantomjs の話があります。 スライドの最後にあるように、やはりまだコレだ!という JS のテスティングフレームワークは存在しなく、今後 JS のテストは『僕らが書きたいテスト』をどれだけ簡単に書ける・書く手法が確立されるかによって流行廃りは決まってくるんじゃないかなぁ、と思ってます。そのうちの一つがスライ
テストにおけるxhrのハンドリングについて 今までの記事は、「ブラウザで動くJavaScriptのテストを難しくしているのはDOMとxhrである」と最初にのたまった割にはDOMのことしか書いてないじゃないか、と鋭い人はちゃんと思ったのではないかと思う。 なのでJavaScriptにおける外部リソース操作の双璧をなすところのxhrについてもちょっと書く。 xhrによる外部リソースの操作を含むアプリのテストを(本物のサーバサイドアプリを使わずに)行う場合の方法は主に二つあると思っていて、 1. テストフレームワークの側で、xhrに対してレスポンスを返すようなモックcontroller(?)を書けるようにしておく 2. xhrそのものをモックオブジェクトにしちゃう 1. はつまり、pushによる自動化を行うようなフレームワークだと何らかの形でWebサーバを起動しているはずなので、その中でxhrか
アプリケーションを開発する上で、避けて通れないもの、それがテストです。とくにブラウザごとの非互換性が大きい Web アプリケーションでは、念入りなテストが必要です。でも、テストはあまり創造的な作業ではないし、やったからといってなにか機能が増えるわけでもない。できるだけ手間をかけずに済ませたいところですね。 そんなわけで、本日は JavaScript 用のテストフレームワークである JsUnit を利用したユニットテストの方法をご紹介しようと思います。 Ruby のユニットテストの記事でも書きましたが、ユニットテストによるテスト・ファースト開発は開発効率の面でも良い影響があります。まだ導入していない方は、ぜひこの機会に使ってみてください。 JsUnit について 今回利用する JsUnit は Java 用の JUnit を参考にして作られた JavaScript 用のユニットテストフレーム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く