現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
Rails & Spine.JS - Using The CoffeeScript Source - Ken Collins @MetaSkills.net
Ruby, JavaScript, Sass, iOS. Stinky Cheese & Beer Advocate. Working at CustomInk and loving it! Our options for JavaScript MVC frameworks are numerous these days. While working on the third major rewrite of my personal bookmarking application, HomeMarks, I decided to learn Backbone.js. Thankfully a local friend of mine recommended that I try Spine.JS. I was immediately hooked! Why Spine.JS? Spine.
Bug statistics are a waste of time
Hi, I'm Gojko, and I help ambitious teams align software delivery with business goals, with the help of Impact Mapping and Specification by Example. I am also one of the authors of MindMup and Narakeet. Lisa Crispin’s talk on defect management techniques for agile teams stirred some emotions at StarEast in early May. The idea that a team might not necessarily need a tool to track defects was, it s
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
無事です - Backnumbers: Steps to Phantasien
2011-03-12 近況 無事です. はいいとして, 先週 Shibuya.js で話してきました (スライド). 空気をよまず JS と無関係の話をしてしまいやや申しわけなかったけれども, WebKit の様々な幻想をぶちこわす開発の様子を知ってもらうことには個人的な使命感を感じておりつまりこれはちょっとした十字軍なのです. JS のテストってなんでむずかしいの? 地震さわぎで自宅警備中の人も多いだろうから, お互いの気晴らしをかねてだらだら書きたい. JavaScript のテストについてぐぐったりついったを読んだりしていると, JavaScript でテストを書くのは大変だとか難しくてやってないという話が多くて不思議におもった. 私は JavaScript を使ってウェブアプリを作る仕事をしたことがなく, いまいち難しさがピンとこない. 趣味でさわっている範囲だと普通に書ける. な
WEB+DB PRESS vol.61 Rails3テスト最前線がすばらしい - tech-kazuhisa's blog
WEB+DB PRESS vol.61の「Rails3テスト最前線」という記事がかなり良かったので、注釈を交えて紹介したいと思います。 何が良かったのか？ 自分はRails2系でTest::Unitを実践していました。AutoTestとYAMLによるデータ投入でおおむね満足していましたが、次のポイントが気になっていました。 YAMLによるデータ投入は重複が多いのでコピペでデータを作成していた。 Test::Unitはログイン処理など共通の処理をくくり出すのが難しかった。 Viewのテストの方法が分からなかった。 しかしこの記事で気になる点がスパッと解消されました。私と同じような人はこの雑誌の記事が役に立つと思います。 ちなみに私はMacのSnow Leopard上でRuby1.9.2を使ってこの記事の内容を試しました。1.8.7を使う前提で書かれている箇所もあるので注意してください。（後で
[Amazon][rails][ruby] WEB+DB PRESS Vol.61 で Rails3 テスト最前線という記事を書きましたのお知らせ - HsbtDiary(2011-02-17)
■ [Amazon][rails][ruby] WEB+DB PRESS Vol.61 で Rails3 テスト最前線という記事を書きましたのお知らせ id:ursm, id:kenchan と共同執筆しました。 主に弊社で Ruby! Rails! Agile! みたいな感じで開発をしている人がふつうにやっていることをちょっと技術よりに倒して解説をしています。だいたい札幌Ruby会議03でオレが話した内容をもう少し深く文章にした感じ。 以下目次。 Railsテスト環境の現在 日進月歩のツールからどれを選ぶか RSpec によるユニットテスト ［基本編］ モデル、コントローラ、ビュー、ヘルパーごとのテスト RSpec によるユニットテスト ［クリーンコード編］ factory_girl でテストデータ、RR でスタブ／モック Request Specsによるエンドツーエンドテスト 画面のテ
![[Amazon][rails][ruby] WEB+DB PRESS Vol.61 で Rails3 テスト最前線という記事を書きましたのお知らせ - HsbtDiary(2011-02-17)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
XP祭り関西にてユニットテストの保守に関する発表 - 千里霧中
先週末、XP祭り関西2011にて「ユニットテストの保守性を作りこむ〜設計・実装の工夫で支えるテストの継続的活用〜」と題した講演をさせて頂きました。 今回は内容として、ユニットテストをより継続活用するためテストの実装とテスト設計の工夫でユニットテストの保守性を高めていく、という話を取り上げさせて頂いています。 ユニットテストの保守性を作りこむ, xpjugkansai2011View more presentations from H Iseri. ※PDF版 今回は、直前にJaSST'11 Tokyoで登壇機会（残務処理が終わり次第報告したいと思います）があり、また仕事も急がしいままという状況が重なって準備でしんどい思いをしましたが、何とか無事に終わりかなり安堵しています。 登壇者として声をかけて頂いた細谷さんや、すばらしいイベントを作り上げているXPJUG関西の方々に深くお礼申し上げます
Jasmineをもう少し詳しく紹介してみる
Jasmine: BDD for Javascript | Jasmine 先日プッシュした Jasmine についてもう少し掘り下げていきます。ただしテストの書き方については触れません。それは公式の情報やすでに詳しく紹介されている記事があります。 まとめJasmine は見た目だけでなく考え方も RSpec の影響を受けているよ多少遠回りでも rubygems 版の Jasmine を使うとテストが本当に自動化できるよわざわざツールを使ってテストしたいということはある程度アプリケーションとして規模が大きいとか、サイトとして規模が大きく JavaScript の数が多くなっているので、人力チェックが大変だということではないでしょうか。 規模が大きくなってきた場合は、ある程度作法（ルール）を用意してそれを守ることが安全、安心なアプリケーションの開発、作成に欠かせません。Jasmine は単に
Rails 3.x 時代のテストフレームワーク
Rails 1.x の頃、テストと言えば Test::Unit であり、Fixtures でした。 この2つがあったからこそ、私は Rails を好きになったんだと言えます。 Test::Unit は Ruby 標準ライブラリの1つですが、Rails はそれを巧妙に拡張して、自らと一体化させていました。 Rails は Web アプリケーションを開発するためのフレームワークであり、同時にその Web アプリケーションをテストするためのフレームワークでもあったわけです。 Fixtures は、テストの対象となるサンプルデータをデータベースに投入するためのツールです。 テストを開始する時点でのデータベースの状態を YAML 形式あるいは CSV 形式で記述しておくと、Fixtures はテストを行う直前にデータベースをその状態に戻してくれます。つまり、Fixtures によって再現性のあるやり
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
ダミーWebサーバを作るライブラリ、wwをリリースしました - moroの日記
近頃はWebAPIを使ったアプリケーションを作ることが増えていると思いますが、自動化テストからのWebAPIへのアクセスはどうやってますか? 私は、自分でstubしたりFakeWeb(レシピ先輩に教わった!!)を使ったりしてたんですが、イマイチしっくりこない部分がありました。で、Sinatraなぞで作ってたんですが、それをgemにまとめましたので、よろしければご利用ください。 http://github.com/moro/ww http://gemcutter.org/gems/ww 概要 ww(Double Web)はいわゆるDouble(mock, stub, spyなど)の機能を備えたダミーWebサーバを簡単に作るためのフレームワーク(笑)です。現状では、以下のようなことが出来ます。 他のAPIサーバを使う場合などに、簡単にダミーサーバを作る そのダミーサーバは自動化テストないから起
[cucumber][テスト] テストデータツールまとめ(2009春夏)
● [cucumber][テスト] テストデータツールまとめ(2009春夏) 調査結果 知見 みんな YAML での Fixture 作成には辟易 (except DHH) DHH は初心者 BDD の流れから全体の fixture でなく必要なデータを作成するのが主流 データ作成ツールは Machinist がすこぶる評判いい (現在のベスト) 集合的なデータが必要な場合は Dataset を使い、その中から Machinist を使う Fake データの作成は Faker gem がこれまたすこぶる評判よし Machinist の発音がわからない 今、cucumber + webrat + mozrepl + firefox + xvfb + rspec + machinist + faker が俺の中で激熱！ 参考 http://github.com/aslakhellesoy/cu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://asciicasts.com/episodes/261-testing-javascript-with-jasmine
http://madscientist.jp/~ikegami/diary/20110219.html
http://www.machu.jp/posts/20100828/p01/
InfoQ: "古典派"TDD 対 "モック派"TDD、これは本当の対立軸だろうか？
