Karma(元Testacular)を使って簡単にテストを実行しよう | DevelopersIO
Karmaとは 昨年、Googleがnode.jsベースのJavaScriptテストランナー、「Testacular」をオープンソース化しました。 このツールは元々AngularJSのためのテストフレームワークとして作られたそうで、 クライアントサイドのJavascriptコードのテストを簡単に実行することができます。 このツール自体はテストランナーで、JasmineやMochaなどのテストフレームワークを使用してテストを行います。 先日このプロジェクトの名前が変更され、「Karma」という名前になりました。 今回はKarmaのインストールからテスト実行(+ Gruntでの実行)までをおこなってみます。 環境構築方法 今回使用した動作環境は以下のとおりです。 OS : MacOS X 10.7.4 Node.js : v0.10.0 npm : 1.2.14 Grunt : 0.4 npm
Puppet や Chef で構築したサーバを RSpec でテストする - Gosuke Miyashita
追記 ここに書いてあることを実現する serverspec という gem をつくりました。詳しくはこちらのエントリで。 Puppet マニフェストをリファクタリングするからテスト書くぞ、ってことで、 puppet-lxc-test-box に書いたように、テストするためのシステムコンテナを簡単に作る仕組みをつくったので、今度は実際にテストコードを書くためのベースをつくってみた。 rspec-lxc-test-box こんな感じでテストが書ける。 require 'container_spec_helper' describe 'nrpe' do it { should be_installed } it { should be_enabled } it { should be_running } end describe 'nagios-plugins-all' do it { shou
CI as a Service ブラウザを使ったJavaScriptのテストをCIサービスで動かす方法のまとめ
Travis CIを始めとするウェブサービスとして使えるCIを使って、 JavaScriptのブラウザテスト(ブラウザ上でJavaScriptを走らせて行うユニットテスト)をやる方法をサービスごとにまとめてみました。 テストフレームワークとして Buster.JS を使用して行います。 Karma (旧Testacular) では公式サイトにも Karma – Travis CI でCI Serviceとの連携方法が記載されているのでそちらも参考にして下さい。 今回紹介するCI Servicesは以下のものです。 Travis CI drone.io BuildHive Jepso CI テスト実行の流れ Jepso CI を除いては、テスト実行の流れ自体は同じなので先に解説します。 Capture用のローカルサーバを立てる テストしたいブラウザで capture URL へアクセスする
JavaScriptのテストツール「testem」が素晴らしいぞ - Mach3.laBlog
この記事は賞味期限切れです。（更新から1年が経過しています） JavaScriptユニットテスト一年生の私が、Nettuts+ のチュートリアルで知ったテストツール 「testem」のお陰で大変捗ったので是非お勧めしたく、ここで紹介してみます。 testem ってなに testem via GitHub : airportyh/testem Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests. 要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応して
Google アナリティクスの新機能「ウェブテスト」でサクッとA/Bテストにトライ！
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
expressやsocket.ioのテストはこんな感じで書いてます、というお話 - アルパカDiary Pro
最近仕事ではNode.jsしか書いてないtoritoriです。 お仕事でもexpressやsocket.ioを使っているのですが WebアプリケーションのテストについてWeb上にあまり書かれていないような気がします。 特にソケット接続した後のメッセージ送信/受信の部分です。 今までのようなHTTPの単純なリクエスト/レスポンスとは手法が異なりますしどうしたものかと。 そこで「自分はこんな感じでテストしてますよー」という記事を書いてみます。 裏を返せば「もっといい方法あるよ！」というのを聞きたいのです＞＜ サンプルについて socket.ioのexample を使います。 ただし、サンプルではログイン時に遷移しない方式なので もう少し実用的な動作に近づかせるため あえてログインURLから遷移するようにし、 セッションもRedisを使うようにしてexpressとsocket.ioでセッションを
JSのCIで椅子を投げられないため方法
状況はかなり改善した 非同期、setTimeout, Ajax系はSinonJSで簡単に Swarm系のツールでDOMのテストも容易に 環境構築も非常に楽になった PhantomJSはバイナリもあるし、ビルドも簡単 Swarm系のツールならブラウザでURLへアクセスすればすぐテスト開始
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
クライアントのテストはzombie.jsでいいんじゃないか - mizchi log
zombie.jsとは jsdomというnode製のDOMシミュレータがあります。これを使えば、ブラウザを使わずにDOMイベントを発行することができます。 zombie.jsはセッション管理とブラウザのアクションを管理するjsdomのラッパーです。 個人的には、Ajaxのテストは無理せずJavaScriptでやれとおもってるので、その点zombieは素直に動いてくれます。 利点 AjaxでDOMを書き換えたりするイベントもテストできる (qt-webkitと比較して) 無茶苦茶早い コンパイルが楽(というかQTは定期的に互換崩れてバイナリ壊れてる… 論よりコード サンプルをアップロードしてあります mizchi/zombie-tester-example https://github.com/mizchi/zombie-tester-example インストール等はReadme見てもらうと
Jenkins と始める Android プロジェクトでの CI - Ant 基本編 - sandbox
Goal Jenkins で達成出来る事は沢山ありますが、この記事では複雑な設定を伴わないで実現可能な、apk の自動生成、テストの自動実行までを対象とします。 またビルドツールも Ant, Maven, Gradle, Ivy 等がありますが、標準でもサポートされており、最小構成な Ant を選択しています。 ※ Jenkins でどこまで自動化したいかによりますが、様々なタスクを実行しようと思うと豊富な Plugin を持つ Maven が便利ではあるので、それはまた別途。 ant でビルド出来る様にする Jenkins で CI するには、まずはプロジェクトをコマンドでビルド出来る必要があります。 Eclipse で作成したプロジェクトでは、そのままではビルドする事が出来ない為、後から Android SDK に含まれるコマンドを利用して Ant 用の build.xml を生成しま
mocha でカバレッジがとれるらしいので試してみた - Write and Run
こんにちは KOBA789 です。最近はおうちクラウドにご執心です。あ、おうちクラウドについては後日書きますね(伏線)。 mocha でカバレッジが取れると聞いて ほうほう。それでそれで? mocha --reporter html-cov > coverage.html && open coverage.html あれー、おっかしいなー とりあえずググります Mocha test coverage なるほど。 こうすればよいそうです $ sudo npm install -g jscoverage $ cd ./your/project/dir/ $ jscoverage ./lib ./lib-cov 自分はなんか npm からインスコできなかったので Github からソース落としてビルドしました。 で、 まだやることはあって、TJ のブログには「index.js を書き換えろよ」っ
「Android Usability Seminar 2012」に参加して来ました - 強火で進め
Android Usability Seminar 2012 http://itpro.nikkeibp.co.jp/android/AUS2012/index.html Android Usability Seminarという名前ですが今回の内容は以下の様にAppleのユーザビリティについての話でした(それをAndroid開発時のユーザビリティに反映しようという事かな？)。 本イベントは、スマートフォンの”デザイン”や“使い勝手（ユーザビリティ）”に注目したセミナーです。デザインの専門家が、アップルのユーザビリティに対するこだわり、使いやすいアプリのユーザーインタフェース、iCloudなどをケーススタディとしたサービスデザインをそれぞれ解説します。 山中俊治さんの講演が聴ける。しかも、無料という事で即応募しました。 多少、メモ書きをしておいたのでここに書いておきます。 雑誌の記事に「Ap
Testing Socket.IO with Mocha, Should.js and Socket.IO Client - Liam Kaufman
I’m currently in the midst of creating an application that utilizes Socket.IO for real-time communication between users. Using mocha and should.js I was able to test objects within my node app. However, I quickly found that there were some odd synchronization issues between clients that the test cases couldn’t cover. To test the interaction between clients I needed a way to programatically communi
Node.jsのテスティングフレームワーク「Mocha」（前編） : ryu22eBlog跡地
2011年12月19日 Node.jsのテスティングフレームワーク「Mocha」（前編） Mochaのチュートリアルに沿ってMocha（読み：もか）を使ってみました。 長いので前編・後編の二部構成にします。 使用するMochaのバージョンは0.3.6です。 はじめにこのエントリーのために書いたサンプルコードは以下に置いておきます。 https://github.com/ryu22e/mocha-example FeaturesGoogle翻訳と辞書を頼りに翻訳しました。もっと適切な訳があればご指摘お願いします。 browser support（ブラウザサポート） simple async support（シンプルな非同期サポート） proper exit status for CI support etc（CIサポート等のための適切な終了ステータス） auto-detects and di
Node.jsのテスティングフレームワーク「Mocha」（後編） : ryu22eBlog跡地
2011年12月21日 Node.jsのテスティングフレームワーク「Mocha」（後編） 前回に引き続き、Mochaのチュートリアルに沿ってMocha（バージョン0.3.6）を使ってみます。 なお、このエントリーはJavaScript Advent Calendar 2011(Node.js/WebSocketsコース)の参加エントリーです。 前回のあらすじアサーションは好きなライブラリを組み込んで使えるよ！同期・非同期どちらのコードでもテストできるよ！テスト実行の前後に呼ばれるコードを書いて、前準備や後始末ができるよ！「あとで書く」用途のテストを書けるよ！便利なオプションがたくさんあるよ！テスト結果の表示形式がすごく見やすいよ！テストの書き方を色々選べるよ！ざっとこんな感じの内容を書きました。 では、前回からの続きです。 Reportersテスト結果の出力形式は以下のとおりです（スクリー
Buster
Buster.JS is not released yet. The JS community doesn't need yet another half finished testing framework. Sign up to get notified when we release a beta. Also, gitorious.org/buster. Bestes Online Casino JsTestDriver style browser capturing Start a server, capture your browsers and run tests from your terminal. Or just run them, and we'll capture a Phantom browser under the hood. Cassino Online Bra
テストフレームワーク mocha - hokaccha memo
JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの
PHP5.3.7のcrypt関数のバグはこうして生まれた
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
qunit-tapを使ってnode.jsのテストをproveで行う 続編 - すぎゃーんメモ
qunit-tapを使ってnode.jsのテストをproveで行う - すぎゃーんメモ の続きです。 qunit-tapは1.0.0がreleaseされました。 https://github.com/twada/qunit-tap/commit/5da16418b6de71e4be186d080a0622e5689e8878 で、@t_wadaさんから追加情報をいただきました。 Node で qunit-tap を動かす際に、ちょっとだけ時間がかかるテストもきちんと通すためには QUnit.init(); の後に QUnit.config.updateRate = 0; が必要そうです。気づくのが遅れてすみません。エントリを修正していただけると嬉しいです 2011-03-28 19:59:24 via web とのこと。 exports = module.exports = global;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js入門
