May 14, 2014 (Updated December 18, 2014) Setting up good testing can be tricky no matter what language you’re in. JavaScript’s flexibility can make your tests powerful in terms of access, but if you’re not careful that same flexibility can leave you tearing your hair out the next day. For instance, how do you test API callbacks? How do you deal with require? Without a proper setup, whether TDD is
I have recently been working on a couple of full-stack JavaScript (MEAN) applications. One of the first projects did not have a well-tested API. Eventually, it turned out the data it returned was not always correct. This shows the importance of testing your APIs. The great news? Testing your Node.JS API is actually quite easy. In this post we will be building a simple RESTful JSON API through test
Yeti はYahoo.comがメインで開発してるNode製のTest Runner的なCLIです。 Yeti自体はテストの構文とかは持っていなくて、Test Frameworksに書かれているようにQUnitやJasmine、MochaやYUI Testなどで書かれたテストを動かすツールになっています。 雰囲気的にはTestemに似ていて、上のTest Frameworksで書いたhtmlページを用意して、 キャプチャー用のURLを作って、そこにテストしたいブラウザをキャプチャーして、テストを書いたhtmlを指定して実行させるという感じです。 (意味的にあんまり変わらないですが、先にテスト用htmlを指定して、ブラウザにアクセスさせるという逆の手順もできます) Yeti自体は数年前からあって、Bunyipとかでもインスパイアされてたりします。 動かしてみる QUnitやJasmine、M
Mon, 29. April 2013 Testing hybrid project is just too difficult. It should be simple to write sources and tests without any boilerplate for Node.js and browsers, and run it headlessly on a build server. Please also read the follow up post: How to run Node.js tests in your browser with Mocha. Running JavaScript directly in Phantom.JS Phantom.JS is a headless WebKit browser. If you have not heard a
テストフレームワークは、busterJSが一番慣れてたんですが、 部署御推薦のmochaをいっちょやってみるかー、と思っているこのごろです。 そしてついでに、 「このへんは、node.jsの場合どうテストするのがかっこいいかしら!!」 と気になっていた部分について、いろいろ調べてみました。 mochaの細かい説明については、公式その他をみてください。 mochaっていうかほとんどshouldですよね。 普通のテスト(libraryやcontrollerのテスト) テストしたいmoduleをrequireして、 shouldもrequireして、テストを書く。これが基本ですね。 // テストしたいmoduleをrequire var hoge = require('../hoge'); // テスト用のライブラリをrequire (mochaの場合は、shouldがあればいいはず) var
「現場で役立つノウハウを」というコンセプトで始まった Practical Sencha Touch シリーズ、今回は第 2 回目です。Sencha Touch のアプリが動作する環境は様々です。場合によっては、特定の端末だけ動作がおかしい、ということもあるでしょう。今回は、そんな時に重宝するツールをご紹介します。 Problem: 特定の端末だけアプリの動作がおかしい。原因を調査するために、詳細な情報が欲しい。 Solution: weinre を使います。weinre は Web インスペクタ リモート（WEb INspector REmote）の略で、端末のブラウザで表示しているページを PC ブラウザ（*）の Web インスペクタを使ってデバッグできるツールです。気になる発音ですが、公式ページによると「”ワイナリー”か”ワイナー”と呼ばれているが、どちらの発音が正しいかは知らない」と
Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.
A Comprehensive Guide to Understanding TypeScript Record Type
README.md Istanbul - a JS code coverage tool written in JS Features All-javascript instrumentation library that tracks statement, branch, and function coverage and reverse-engineers line coverage with 100% fidelity. Module loader hooks to instrument code on the fly Command line tools to run node unit tests "with coverage turned on" and no cooperation whatsoever from the test runner HTML and LCOV
最近仕事ではNode.jsしか書いてないtoritoriです。 お仕事でもexpressやsocket.ioを使っているのですが WebアプリケーションのテストについてWeb上にあまり書かれていないような気がします。 特にソケット接続した後のメッセージ送信/受信の部分です。 今までのようなHTTPの単純なリクエスト/レスポンスとは手法が異なりますしどうしたものかと。 そこで「自分はこんな感じでテストしてますよー」という記事を書いてみます。 裏を返せば「もっといい方法あるよ！」というのを聞きたいのです＞＜ サンプルについて socket.ioのexample を使います。 ただし、サンプルではログイン時に遷移しない方式なので もう少し実用的な動作に近づかせるため あえてログインURLから遷移するようにし、 セッションもRedisを使うようにしてexpressとsocket.ioでセッションを
nodeのアプリケーションに対するテストをmochaで書いていて、railsのアプリケーションに対するテストをrspecだとこう書くけどこれはmochaではどうすればいいのだろう、というのが幾つかあったので書き留めておきます。今回解説に使うコードは全てgithubにあるので、そちらも参考にして下さい。 今回テストの対象となるアプリケーションは以下の様なものです: socket.ioを使ってユーザ間でメッセージのやり取りが出来る ユーザは、最初にサーバに接続した歳にユーザ名を含んだjsonをサーバに送り、サーバはそのjsonを受け取ったらそのユーザ名をredisに書く それ以降は、ユーザはユーザ名とメッセージを含んだjsonをサーバに送り、サーバはそのjsonを受け取ったら他の全てのユーザにそのjsonを送る それでは早速解説していきます。 テストファイルの名前 テストを実行するのには、mo
突然ですが 私立・プログラミングキャンプ 2012 東京大会 - #upcamp : ATND に行ってきました。意味不明だと思いますけど、ずっと電磁リレーで4ビット加算器作ってました。 KOBA789/relay-sim · GitHub KOBA789/four-bit-adder · GitHub ちなみに時間がなくて回路がバグってます で 今回はそのとき用いた怠惰なテストの書き方についてです。 テストを書くというのはダルいもんで、まぁとにかくダルいもんで、昔書いたテストとかなんだか意味わからんことになってたり、個人的にはユースケース的なテストがあるとサンプルの代わりにもなって便利だと思ってるんですけど、テストフレームワークとか使うとそういう雰囲気もなくなっちゃって(そりゃ当然だが)あまり嬉しくないので……(ry という愚痴はさておき、手軽に書けて嬉しいのは自明です。 どこに書くか
目標はgrunt + phantomjs + jasmineの自動テスト環境 先日の大なごやJS Vol.3で、@_tk84さんが発表なさっていた、PhantomJSで自動テストにインスパイアされて、Gruntでそのあたりをコントロールできるようにしました。 今回のポイントは下記。 .coffeeを保存したら、.jsに自動でコンパイル .jsの更新を検知して、SpecRunner.htmlを自動生成 このとき更新された.jsと、対になるテストコードを含んだSpecRunner.htmlが生成される phantomjsで、SpecRunner.htmlを実行した結果を標準出力 出力をgrowlnotifyに渡してデスクトップ通知 @_tk84さんの元ネタのほうでは、EmacsとRubyな環境でしたが、自分はエディタには依存せず、nodeの実行環境だけで何とかできるように構成しました。 aho
Node.js のテストフレームワークは主要なものはここにありますが、どれがいいのか迷ったので試してみたもの、ドキュメントを読んで良さそうものについて印象を記録しておきます。 ちなみに、選出の基準は「ドキュメントが充実していること」です。 追記 ブコメで[twitter:@meso]さんが指摘されてますが、Tobiというブラウザの動作をエミュレーションするモジュールもあります。あと、nClosureもテスト機能をふくんでいるので追加しました。 更に追記(2012/2/23) この記事を書いた時点では存在しなかった以下のテストフレームワークを追加しました。 Mocha Buster.JS テストフレームワーク mocha(http://visionmedia.github.com/mocha/) Express等の作者であるTJが新たに開発したテストフレームワーク こちらの記事がよくまとまっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SpookyJS & mochaでnode.jsのクライアントサイドテスト
Blogger
