テストフレームワーク 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の機能なの
食べログ×クックパッド合同勉強会 に行ってきた #tabepad - techlog
はじめて白金台の駅で降りた。なんだこのおしゃれな感じは…。昔は毎日こんなところを通過していのか。 電車を降りててくてく歩いて行くと、そのなかでも目を引くかっこいいビルがあって、そこの5階がクックパッドのオフィス。エレベーターを降りてちょっと曲がるとすぐに広いキッチンがあって、みんなでなにかを作っている。すごく美味しそうな匂いがして、炒めもののいい音が聞こえるする。 19時ちょっと前のお腹の減った僕には辛いくらい。 前置きが長くなったけど、食べログ×クックパッド合同勉強会に行ってきた。30人の狭き門で、抽選に当たって嬉しかった。 食べログ×クックパッド合同勉強会のお知らせ~開発の裏側お見せします~ « クックパッド開発者ブログ 発表のタイトルはこんな感じ。 「いかにしてユーザ体験を保証するか」クックパッド 高田 悟史さん ([twitter:@satoship]) 「Jenkins + Se
Twiwt:Blog / jugyo : scala の BDD フレームワークである specs について調べた
scala の BDD フレームワークである specs について調べた こんな感じのクラスをテストするとする。 class Foo { def foo: String = { "foo" } } 基本形(Eclipseの場合ScalaApplicationとして実行可): import org.specs._ object FooSpec extends Specification { "Foo#foo が 'foo' を返す" in { val foo = new Foo foo.foo must_== "foo" } } JUnit として動かす場合(EclipseでJUnitで実行可): import org.junit.runner.RunWith import org.specs.runner.JUnitSuiteRunner import org.specs.Specific
RSpec + capybara-webkit で ヘッドレステスト - LocalScope::
ここしばらく、Rails 3.x ベースで簡単な開発をしています。 どうせやるなら、新しいことやらないと、ということで、今回は Behavior Driven 開発をしようとしてました。Cucumberでの、振る舞いベースの要求仕様策定から、RSpecを用いた Test Driven な開発へと落とし込んで行く方法です。The RSpec Bookやら、Continuous Testing: with Ruby, Rails, and JavaScriptを読みつつ、色々と実験してました。 そんなわけで、いくつかTipsなどまとめたいと思っているのですが、とりあえず、役に立ちそうなことを先に書いみようということで、前置きが長くなりましたが、capybara-webkitについて。 RSpecは、 「プログラムの振舞 (behaviour)」を記述するためのドメイン特化言語 (DomainS
JavaFXのWebViewでSeleniumみたいなWebテストやってみたら面白かったんだけど 2011-05-30 - きしだのはてな
JavaFX2.0のWebViewで、Javaからブラウザが操作できるようになって、これをSeleniumが組み込んだらおもしろいことになるだろうなと思ってたのですが、よくよく考えると、SeleniumナシでWebサイトのUIテストが簡単に書けることに気づきました。 ということで、まずはテスト対象のサイトをつくってみます。 最初の画面(first.html)。テキストフィールドがあって、OKボタンを押すと「ほんと？」という確認ダイアログがでて、「OK」を押すと次の画面に行きます。 <!DOCTYPE html> <html> <head> <title>テスト画面</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <h1>テスト画面</h1> <form id
テスト自動化に関するスライドの紹介
みなさんこんにちは。@ryuzeeです。 SlideShareでテスト自動化に関する良いスライドをみつけたのでご紹介します。 Agile Toolkit http://www.slideshare.net/nverdo/agile-toolkit-mo-conf 参考になる部分は以下の3スライドでしょう。順に説明していきます。 手動テストのコストプロジェクトの初期は以下のような状況です。 テストする項目は少ない手動でテストを完了するのも簡単まだプロダクションでもないし、問題があって影響を受けるのは限定された人だけしかし時間がたつにつれて 手動でのテストにはとても多くの時間がかかるようになる製品が出荷されてしまうと、バグによってとても多くの人が影響を受けることになってしまうという状況に変わっていきます。 右のグラフは手動でテストを行った場合のテスト時間の推移を示していますが、見て分かる通り、
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
Node.jsとJasmineでJavaScriptのBDD環境 - ひげろぐ
Jasmineでスペックを書いていく環境を整えるのにJasmine Toolなるものを試してみた。 なお最近なんだかJasmine押しですが、Jasmineしか試してないだけであり他意はありません。 2011/01/12追記 Jasmine Toolはブラウザを介するもので、普通のJasmineとやってることは変わらない。 Node.jsを使って動かすのであって、Node.jsのソースをテストするのではない。ややこしいけど。 Node.jsのモジュールのテストにはjasmine-nodeやvowsが向いていそう。 両方試してみてjasmine-nodeについては書いた。 Jasmine Tool そもそもこれはなんぞや Jasmine ToolはNode.jsで動くコマンドラインのツール。 簡単に言うとrubygemsのjasmineのNode.js版。 rubygems版との違いはRub
JasmineによるJavaScriptのテスト その1 - サーバーワークスエンジニアブログ
JasmineによるJavaScriptのテスト その1 こんにちは、プログラマのおぐらです。 弊社のクラウドマネージメントサービス Cloudworksでは、JavaScriptのテストにJasmineというフレームワークを利用しています。Jasmine自体はとてもよく出来ていて便利なソフトウェアなのですが、まだリリースされて日が浅いということもあってあまり日本語の情報がありません。そこで、Cloudworks担当のエンジニア Y氏にJasmineの社内向けチュートリアルを作ってもらったところ、なかなかの大作が仕上がり、社内だけで利用するにはもったいないデキでしたので技術ブログのコンテンツとしても掲載させていただくことになりました。 これから何回かに分けて掲載していきますので、「JavaScriptをどうテストしよう？」とお悩みの方はぜひ参考にしてみてください。 Jasmineとは？ J
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
テストマネージャになったら，どうする？ SEの視点での書評：「現場の仕事がバリバリ進む ソフトウェアテスト手法」 - 主に言語とシステム開発に関して
現場の仕事がバリバリ進む ソフトウェアテスト手法 作者: 高橋寿一,湯本剛出版社/メーカー: 技術評論社発売日: 2006/05/10メディア: 単行本（ソフトカバー）購入: 29人 クリック: 469回この商品を含むブログ (28件) を見る ソフトウェアテスト手法，技術評論社，2006。 テスト工程を「テストマネージャ」の観点から見た場合， 何から手をつけて，どうやって進めていけばよいのか。 特に，テスト自体の要件定義（マスターテストプラン）や，テストの基本設計（テスト分析）の成果物を， どのように文書化したらよいのか。 そういった，いち担当者レベルよりももっと上の，マネージャレベルでのテスト工程の進め方が書いてある本。 開発の場合，工程の分類は下記のようになる。 立ち上げ 要件定義 基本設計 詳細設計 実装 テスト リリース ここで，テスト工程だけに注目してそれをさらに細分化し，上記
より良いテスト駆動開発を行うためのチートシートの紹介
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
Google Test 1.6.0 が正式リリース - エンジニアのソフトウェア的愛情
RC2が公開されたのでブログでコメントしておこうと思いつつ。うかうかしていたら、あっというまに正式リリース。 GitHub - google/googletest: Google Test 最近はC++でまともにプログラミングをしていないのもあって、Google Testもトピックがあったときにちょこっと言及するぐらい。以前まとめを書いたのがバージョン1.3.0のときだから、それから3つもバージョンが上がってしまった。 googletestまとめ - エンジニアのソフトウェア的愛情 アナウンスはこちら。04/18付け、日本時間では今朝のリリース。 Google グループ まだダウンロードしただけでキチンと触れていないんですが、おさらいも兼ねて変更点を書いておきます。せっかくなので1.3.0以降の変更点をまとめて一覧。 ドキュメントやコードを読んでみた内容も合わせて書いてみますが、実際に使っ
【資料公開】自動テスト vs 手動テスト
みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたところ自動テストと手動テストに関する良いスライドがあったので、翻訳して公開します。 ライセンスはオリジナルに準じてCC BY-SA 3.0とします。 内容としては、僕自身も一貫して主張しているテスト自動化の必要性の話で、主に以下の観点で記載されています。 作業量とコスト再利用性ユニットテストによる良い設計への誘導手動テストのリスクリスクマネジメント書き方が若干極端な箇所もあると思いますが、全体としてはかなり分かりやすいのではないでしょうか。 なお、テストの自動化に際しては、必ずしも全てのテストを自動化「しなければならない」わけではありません。 スライドではROIの例があがっていますが、テストの自動化のコスト＞手動コストの１回あたりのコスト×実行回数になる場合もあり得るので、ROIやテスト自動化によって得られる効果に
クラスのモックも作れるMoqってステキ - present
単体テストでモックを使うときは、ほとんど Moq を利用するようになりました。 Moq のススメ - present moq - The simplest mocking library for .NET and Silverlight - Google Project Hosting Moq のステキなところは、インタフェースだけじゃなく、クラスでもモックが作れること。テストのためだけにインタフェースを用意するのって、正直面倒ですよね。 ただし良いことばかりではありません。クラスのモックを作るためには、動作を指定したいメソッドを virtual にしておく必要があります。これに抵抗感がある人って、多いんじゃないでしょうか。「公開するクラスにはできるだけ virtual なメンバを持たせたくない」という気持はわかるので、モックを作りたいクラスには、ちょっとした対策を取っています。 publ
テストのプロセス - やさしいデスマーチ
というわけで、「はじめて学ぶ ソフトウェアのテスト技法」を読み直しているので、メモ*1。 テストとは？ IEEE 標準規格 610.12-1990による定義。 ある特定の条件下でシステムまたはコンポーネントを操作するプロセスであり、その結果を観察または記録して、システムまたはコンポーネントのある側面を評価すること テストの成熟度 テストに関して以下の５つの成熟度（レベル）がある レベル０ーテストはデバッグと同等 レベル１ーテストとはシステムが動くことの確認 レベル２ーテストとはシステムが動かないことの確認 レベル３ーテストとはシステムのリスクを減らすこと レベル４ーテストとはシステムの品質を高める為の規範 テストケース テストの実装。テストケースは、適当に作るのではなく、正しく「設計」することが必要。 入力 出力 実行の手順 すべて曖昧であってはテストケースとして不完全。 テストの分類 ブ
90-コードを見る人のためにテストを書く - やさしいデスマーチ
「プログラマが知るべき97のこと」の90個目のエピソードは、テストに関する話です。きのこ本には本当に多くのテストに関するエピソードがあります。テストの書き方、目的、心構えなど様々なテストに関する重要なトピックがありますが、このエピソードでは「誰のためのテストか？」という点について書かれています。56ｰ未来へのメッセージなどでも書かれていますが、プログラムを現在の自分の自己満足にしてはなりません。テストも同様であり、自分の為や製品の品質の為ではなく「コードを見る人のため」にテストを書く事が良いテストの条件です。 ・コンテキスト、出発点、満たすべき事前条件がわかる。 ・ソフトウェアがどのように起動されるかがわかる。 ・期待される結果と、確認すべき事後条件がわかる。 これらの条件を満たすテストは、良いテストです。一見、当たり前のようにも思えますが、他人がテストコードを読んだとき、これらの事が明確
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1048253’s gists
Cloud developer documentation - Atlassian Developer
phantomjs - Project Hosting on Google Code