Web Audio API でもテストがしたい - 音の鳴るブログ
開発中に node.js でもテストできるように Web Audio API のテスト用APIを書いた。 最終的なオーディオ処理の結果については耳で確認するしかないのだけど、音を聞くまでもない段階のときに AudioNode(音を出す部品) がどう接続されているのかを調べたりできる。便利だと思うけど、これがあって嬉しい人は少ないと思う。あるのはインターフェースと型のチェックくらいで、信号処理的なのは一切していません。こういう事ができます。 グラフの確認 JSON化すると接続状態が返ってくるのでテストできる。 var ctx = new AudioContext(); var osc = ctx.createOscillator(); var amp = ctx.createGain(); osc.type = "sawtooth"; osc.frequency.value = 220; o
power-assertでJavaScriptのテストをする ブラウザ編
power-assertという単純なアサーションでも、テストが失敗した時に分かりやすい情報を出せるテストライブラリ/ツールについての記事です。 前回、power-assertの使い方 Node.js編 | Web scratchではpower-assertの動作やNode.jsプロジェクトでの簡単な導入方法について解説しました。 前回のpower-assert + gulpで紹介したプロジェクトをそのまま使っていくので、見ていない場合はそちらから見ていたほうがいいかと思います。 今回は、ブラウザでのpower-assertの動かし方とデバッグについて書いていきたいと思います。 今回扱う実行環境 Node.js ＜＝ 前回 ブラウザ Browserify 前回やったこと まずは前回紹介したgulp + power-assertのプロジェクトを元にやっていきます。 azu/power-asse
power-assertの使い方 Node.js編
Power Assertとはassert(a === b); のような単純なアサーションでも、 Assert失敗時(テストが通らなかった時)に分かりやすい情報を表示できるようにする機能の事を言います。 JasmineやChaiが持つshouldやexpect等言った豊富なアサーションを覚える必要なく、 シンプルにassert()を使うだけでも十分な失敗時の情報が得られるため、沢山のアサーションを使い分けしなくていいというメリットがあります。 この記事ではPower AssertのJavaScript実装であるtwada/power-assertの使い方について紹介します。 記事を読む前に このNode.js編とブラウザ編で分けるぐらい長い記事となってるので、 お忙しい方は5分ぐらいで分かるpower-assertというスライドもあるので、そちらを読んでざっくり把握してみるのもいいでしょう。
jsでTDD！MochaとChaiとsinon.js入門 - lxyuma BLOG
※この記事は社内勉強会向けの資料の下書きです。書きなぐりの下書きで見直すと最後の方の文書がヤバいので、いつか書き直します。読み辛い所は申し訳ないです。 概要 TDD テスト自動化とTDDを整理 TDDとBDDの違い Test Framework in javascript QUnit/jasmine/mochaについて、違いやメリデメを知る mocha 基本的な書き方 アサーションライブラリのメリデメを整理する chai 記述形式の違い整理 基本文法 sinonjs spy stubs mock TDD Test Driven Development テスト駆動開発 by ケントベック 特徴 xUnit系/BDD系のテストフレームワーク使う テストするコードも実装 テストファースト 実装の後にテストするのではなく、テストを先に書いて実装する サイクル Red(失敗) => Green(通過
chaiのインターフェース - 音の鳴るブログ
chai にはこういうインターフェースがあるけど expect(true).to.be.true; こういうアサーションは使わずに、普通に equal とかで書いたほうが良いと思う。 expect(true).to.equal(true); プロパティ止まりのアサーションだと、こういうのがどちらも通ってしまう。 expect("Mr.Big").to.be.with.you; // あってそう expect("Skid Row").to.be.with.you; // カバー？？ 最後の you というプロパティは存在しないので、単に undefined が返るだけの無意味な式になっているのだけど、アサーションが失敗するわけじゃないので問題ないみたいになる。最初に書くテストは失敗するというのを徹底すれば良いかもしれないけど、それで発見するのはテストの書き方のテストという感じであまり意味が無
phiary
Node.js６連投. 第６弾! npm と Node.js 上で require を使ったモジュール読み込みの仕組みについてメモ Node.js 用に作った自作モジュール『merger』を npm で公開してみた Node.js 用の自作モジュールの作り方メモ Node.js 用に作った自作モジュールを npm に登録して公開する方法 JavaScript テストフレームワーク『Mocha』の使い方メモ JavaScript テストフレームワーク『Mocha』をブラウザ上で使う方法 <- いまここ 前回に引き続き Mocha の使い方についてのエントリーです. 今回はブラウザ上, つまりクライアント側で Mocha を使う方法について解説します. 何もインストールする必要がなく, dom 系のテストも出来るのでオススメです!! Code test.html テストプログラムの html
小さくKarmaとmochaでテスト環境を整える。
流行りにのって(遅い！)Angular.jsを試してみようと思ったのですが、Angularの前に気になって仕方がないことがあります。 「Karmaが便利なんだろうけどさっぱりわからん」 公式のチュートリアルではKarmaがすべて「下ごしらえ完成した状態」になって提供されます。動いてくれているのですが、なぜこう動いてくれているのかさっぱり分からなくて何となく気持ち悪い。 Karmaについて調べようとしたのですが、以外と情報が少ない。公式ではいきなり動画だったり :( ということで、小さくKarmaとmochaでテスト環境を整える事を目的としたメモ・備忘を文章で残します。 ファイル構成hello.js var hello = function() { return "hello"; }; hello.test.js describe("karma and mocha testing", fun
テストを始めるまでのヤク狩り - Memo
メモ。 色々言い訳作って JavaScript のテストを書かなかったけど、さすがにマズいので書いてみる。 なお、ここでの JavaScript のテストは Web ブラウザで動く JavaScript。 テストを始めるまでに敷居が異様に高いと感じたのでまとめる。 典型的な yak shaving! テストフレームワーク フルスタックな Jasmine か、色々選択できる Mocha か。 アサーションライブラリ Mocha を選択する場合は chai がよさそう。 理由は chai だと、expects や should や xUnit 風どれでもいけるから。 テストダブル とりあえず Sinon.js を使っとけという雰囲気。 テストランナー Grunt.js + Jasmine と Karma + Mocha を試す。 Gurntfile.js module.exports = fu
ソフトウェアテストの言葉入門 #kyon_mmAdvent - うさぎ組
kyon_mm Advent Calendar つぎのリンクにあるAdventCalendarの17日目です。 http://connpass.com/event/1457/ これは非常にながーい時間がかかりましたが、いぜんにid:kura_replace(@PG_kura)さんのWeb プログラミングってこんな感じじゃなかろうか - 偏見プログラマの語り！という素晴しい記事へのおへんじとなります。 もう半年近く書き足しては書き直しの日々でございましたが、ようやく公開できるようになりました。 @PG_kura さんがおっしゃっている「テストのあり方：テストコードはこう書きましょうという汎用的なコンセプト」については当連載での後半で書きます。 ここに書いてあることが僕がNagoya.Testingという場で伝えたい事でもあるなぁと書いていてしみじみと思いました。 このような機会を頂きありがと
JavaScript UnitTest Patterns
ここでは以下の順番でSinonJSとJsTestDriverを使用したJavaScriptのUnitTest Patternsを紹介します。 初期化の遅延非同期実行の同期化html, cssのテストイベントのテストその他問題になりうるコード初期化の遅延UnitTestを行う場合、まずは初期化functionが自動的に実行されないようにしましょう。 初期化functionをこちらの任意のタイミングで実行できるようにすることにより事前に対象外のコードをstub化したり、必要なfunctionへspyを仕込んだ状態でfunctionを実行できるようになります。 UnitTestの場合のみ初期化を遅延する一番簡単な方法はUnitTest実行時のみ条件分岐で初期化を止める方法です。 $(function () { if (window.sinon) { init(); } }); この方法は簡単かつ
ブラウザの操作を自動化するためのWebサービス、Jungpooをリリースしました。 - mitoma_ryoの日記
昨日５月５日に、ブラウザの操作を自動化するためのWebサービス、Jungpooをリリースしましたのでサービスの簡単な紹介をしたいと思います。 いやー、GWを利用してなんとか開発・リリースにこぎつけることができました。 Jungpooについて Jungpooというサービスなんですが、どんなサービスかというと「ブラウザの操作を自動化するためのWebサービス」となっております。 サービスURL→https://jungpoo.com/ 「え？それってどういうこと？SeleniumとかWebDriverみたいなの？」 と思った方、正解です。 JungpooはSeleniumやWebDriverで作るようなテストケースをWeb上で作成することができ、そのままJavaアプレットで実行することができるサービスです。 現在、Seleniumなどでのブラウザを使った自動テストの実行にはいくつかの方法がありま
JavaScriptの新旧ユニットテストツール - 強火で進め
「エンジニアサポート新年会2012 CROSS」のセッションの1つでJavaScriptのセッションが行われました。 エンジニアサポート新年会2012 CROSS http://tech.nifty.co.jp/party/2012/index.htm JavaScript 八面六臂 2回戦 http://tech.nifty.co.jp/party/2012/sessions/bRoom2.htm そこでJavaScriptのユニットテストツールの話が有り、新旧のツールが上げられていたのでメモ。 昔から有る QUnit 、Jasmine 。新しく出てきたものとして mocha 、Buster が紹介されました。 QUnit 公式サイト。 QUnit - jQuery JavaScript Library http://docs.jquery.com/QUnit 【レポート】jQueryテ
xUnit成熟度モデル 〜あなたの組織はどのレベル？ - 谷本 心 in せろ部屋
本エントリーは、Software Test ＆ Quality Advent Calendar 2011の10日目です。 http://atnd.org/events/22833 前の9日目は @m_seko さんの 「負荷テスト対象のWebアプリがこういう非機能要件(＋α)を備えていたらいいのにという願望」です。 http://d.hatena.ne.jp/sekom/20111209 普段、品質やテストなどには興味なさそう（？）にしている私ですが、 たまには、エンジニア視点から、テストについて語ってみましょう。 xUnit成熟度モデルって？ xUnit成熟度モデルとは、 組織がxUnitをより適切に利用できるようになることを目的として 遵守するべき指針を体系化したものである。 あわせて読みたい : 能力成熟度モデル統合 (CMMI) - Wikipedia 正味の話で言うと、僕がJUn
バグのないプログラムを作るための技術 - eomole blog 4 くらい
2015/12/10 追記: バグを本気で無くしたい方はこんな良く辺鄙なブログなんて見ずにソフトウェアエンジニアリング系の国際学会に行くなり、そこの論文を読むなりするといいと思います。ICSEなんかは日本語の勉強会資料もあってとっつきやすいでしょう。 バグのないプログラムを作る方法について色々聞きかじったことを, 脈絡なく訳の分からない説明でつらつらと書きならべます. テスト 割と古典的な方法ですね. プログラミングコンテストでもお馴染みの方式です. Java だと JUnit (4) みたいなのを使います. 手作りケース とりあえず試してみるケース コーナーケース ミスの発生しやすそうなところを突くためのケース ランダムケース ランダムに爆撃するためのケース みたいなものを作って, 仕様とマッチするか確認します. 当たり前ですが, 基本的には下手な鉄砲も数撃ちゃ当たる方式なので, 運が悪
Selenium WebDriver + Excelファイル でデータ駆動型テスト - suzukij's diary
前回の続きです。 Selenium WebDriverのテストケースを試験的に運用してみたのですが、各画面の入力項目や期待値があるため、通常よりも扱うパラメータが多くなってしまい、テストケースの管理がしづらくなったり、シナリオテストのコードの見通しが悪くなったりしてしまいました。 そこで JUnit Parameterized と XLSBeans を組み合わせてパラメータをExcelファイルで管理し、データ駆動型テスト(異なるテストパスでデータを変更できるテスト)をしてみたところ結構イイ感じだったので書いておきます。 JUnit Parameterizedとは？ @Parametersアノテーションを記述したメソッドでテストデータの設定をし、テストデータの数だけテストケースを繰り返し実行してくれる機能です。 テストケースの内容を変えずにパラメータのみを変更して繰り返しテストを実行したい場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
Writing tests for the Web Audio API – Chris Lowis
TDD のこころ @ OSH2014
Build and implement a single sign-on solution
IDEA * IDEA
