Amazon.co.jp: The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends (The Facets of Ruby Series): Chelimsky, David, Astels, Dave, Helmkamp, Bryan, North, Dan, Dennis, Zach, Hellesoy, Aslak: 本
RSpec のすごいところ - kなんとかの日記
(注: 以下の内容は、RSpec ユーザの間で広まっていることでもなく、もちろん RSpec 開発チームの公式な見解でもなく、あくまでワシの個人的な見解です。) RSpec のすごいところは、コードに対してではなく仕様に対してテストを書くことを明確にしたことだと思う。何を今さらと言われそうだけど、今さらになってようやく気づいたニワトリ頭ですまんかった。 ワシも最初は、「assert_equal(expected, actual)」のかわりに「actual.should == expected」と書くかっこよさに目を奪われて、テストコードを自然言語に近い形で記述するのが RSpec のすごいところだと勘違いしてたし、それが「TDD (Test Driven Development)」から「BDD (Behaviour Driven Development)」へという新しい潮流だと勘違いしてた
RubyKaigi2010に関連していま思っていること, Pivotal TrackerのGetting Startedの翻訳, 2年前の動画をいま見てくれた人がいたということとRSpecのMacroについて - 角谷HTML化計画(2010-04-14)
■1 RubyKaigi2010に関連していま思っていること ……は、Web日記に書くんじゃなくて古式ゆかしくメーリングリストというころに投稿してました。日本Rubyの会MLというメーリングリストがあるのです。 [ruby:2349] Re: [ANN] 日本Ruby会議2010 スポンサーシップのご案内 [ruby:2350] Re: 日本Ruby会議2010の企画にRubyの会として出せるもの/出すと良いものとか Tags: rubykaigi2010 ■2 Pivotal TrackerのGetting Startedの翻訳 Web日記じゃないところに書いたものつながりでお知らせ。 必要に迫られて以下をリリースしました: Pivotal Trackerの「Getting Started」を翻訳しました(アナウンス) Pivotal Tracker: はじめかた(翻訳) 私たちの役にた
RSpec の入門とその一歩先へ、第2イテレーション - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第2イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 #coffee.rb の写経会に招かれた(というよりは押しかけた?)ので、先日の RSpec チュートリアルの続きを記します。このエントリは写経会に参加しながらのライブ更新でした。 (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 前回終了時点のコードと実行結果 前回終了時点でのコードを以下に記します。 message_filter.rb class MessageFilter def initialize(word) @word = word end def detect?(text) text.include?(@word) end end message_filter_spec.rb r
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
ラシウラ - RSpecのspecの書き方
(5/27: はてブ5人付いてたので、読みやすく直した) BDDツールとしてRSpecは使えたとしても、実際どうspecを書いていいかで悩むだろう。検索で引っかかるのは、動作解説が中心で、どうspecを書くべきかについてまで触れているものはほとんどない。そこで、物になるspecの書き方を分析してみる。 まず、Exampleを見て分析してみる。 http://rspec.rubyforge.org/examples.html http://rspec.rubyforge.org/documentation/index.html http://rspec.rubyforge.org/documentation/mocks/mocks.html これらを眺めて感じたこと あるまとまった性質ごとに :shared=>true で describeを書く 別途、クラスごとにコンテキストを作るdesc
RSpecを日本語の仕様っぽくするには - ナマケログ
今仕事でRailsアプリケーションを組むときに、test/unitじゃなくてRSpecを使ってる。mock周りの使い勝手がいいとか、語彙が馴染みやすいとかいろいろ魅力があるんだけど、その「可読性」を保つにはなかなかコツがいると思う。言うまでもなくRSpecはRubyのコードを「英語の表現として自然に見える」ようにすることを意図して語彙や書き方を決めている。これは英語圏のエンジニアには非常に素敵なことではあるんだけど、英語が苦手で英作文なんて始めて数分で泣きたくなるようなへたれ外国語学部生にとっては正直やっかいだし、周りの人達の大半は英語に慣れていない人達*1だったりするので、せっかく可読性が高い綺麗な表記でさえむしろ意図を理解する妨げになったりする。いっそドイツ語で書いて「お勉強」に活用してやろうかという衝動に駆られたけども、誰一人として読めない上に一週間後の俺ですら理解に苦しみそうなので
RSpec and Cucumber での Outside-In 開発
Table of Contents Open Table of Contents The RSpec Book モックとスタブ 関連するサイト The RSpec Book 海外では多くなってきているベータ版ブック。まだ完成していない本なのだが、ベータ版ということで購入できる。流石に紙ではやらない(紙のベータ本をやっているところがあるにはあるらしい)が、章が埋まる度に電子媒体がアップデートされ、販売元にあるフォーラムに読者からの声、著者からの返答が書き込まれる。本の正式出版までの間に読者にお金を払わせた上で、レビューまでさせるという、なんともうまい商法だ。。 RSpec、Cucumber を手探り状態で試していたのだが、まとまった情報が欲しく、先月 RSpec の開発/メンテナンスのリーダーである David Chelimsky を始めとした凄腕スタッフによって書かれている RSpec B
HTTP通信を伴うライブラリのRSpecを書く - しばそんノート
伴う、というかそれがメインの機能だったりもするわけですが。 少し前、以下の記事でごく単純なOAuthコンシューマの実装を行いました。 OAuthコンシューマの仕組みと実装 〜 Ruby編 - しばそんノート この小さなライブラリの使い方は以下の通りです。 require 'simple-oauth' simple_oauth = SimpleOAuth.new('COMSUMER-KEY', 'COMSUMER-SECRET', 'ACCESS-TOKEN', 'TOKEN-SECRET' ) response = simple_oauth.get('http://example.com/') response = simple_oauth.post('http://example.com/', :foo => 'bar') これで全機能です。*1 getやpostメソッドでは、内部でNe
RSpecで独自のマッチャを定義するもっとも簡単な方法 - ちなみに
RSpecでテストを書いていてよく hoge.instance_variable_get(:@piyo).should == 'hehehe' とか書きますよね 毎回indtance_variable_getを書くのが面倒なのでマッチャにしておくと簡単にテストできます Rspec::Matcher.define :be_in do |name, val| match do |klass| klass.instance_variable_get("@#{name}").should == val end end be_inというマッチャを定義して、インスタンス変数の取得から比較までをくるんで置きます ついでに@hogehogeと書かなくて良いようにしています これでテストからは以下のように使えます hoge.should be_in(:piyo, 'hehehe') エラーメッセージなど、も
ehendri's Ruby-Slider-Puzzle-Sample at master - GitHub
This repository is private. All pages are served over SSL and all pushing and pulling is done over SSH. No one may fork, clone, or view it unless they are added as a member. Every repository with this icon () is private. This repository is public. Anyone may fork, clone, or view it. Every repository with this icon () is public.
つくったLRUHash - moroの日記
私はid:fistfvckさん(ですよね? お名前確認してなかったのでちと不安)と一緒にコードを書きました。仕様はこんな感じ。 Hashぽいインターフェースが欲しいとの要件だったので[]と[]=をまずは実装(上2つのexample)、その後100個という最大値を挟んでのLRU的機能を実装してみました。実際のストレージは、ふつうのHashへのdelegateで。継承したペアも多かったんですが、私たちは「コレはis-a Hashじゃなかろう」ということで委譲を使ってみることにしました。Forwardableは凄く便利。 このあたりのテストを書いてみると、LRUぽい機能はと=で何かやれば良さそうだぞ、というのが導出されてきます。また、テストを書いてみると、実際のクライアントとしてはcacheされていてnilなのか、そもそもキャッシュされていないのかを見るためにhas_key?系のメソッドも欲しか
RSpec 本 1 章のメモ - たかみやの日記
Beta Book よくわからなくなったら Eratta をチェックしようhttp://pragprog.com/titles/achbd/errata Important Information for Beta Readers RSpec の開発者が書いてるから、本に載ってることはまだリリースされていない最新の機能。 注: 下のページを参照すると本に書かれている機能はすでに RSpec 等の最新版に取り込まれているようだ。http://wiki.github.com/dchelimsky/rspec/code-for-the-rspec-book-beta Introduction Test Driven Development は多くの開発者にとってむずかしいことがわかった。Dave Astels は有名な記事 "A New Look at Test Driven Developme
ヽ( ・∀・)ノくまくまー(2009-03-30)
● [テスト] should change に見る UnitTest と RSpec の違い Yugui さんに Proc#should change が便利だと教わった。 Spec::Matchers::Change Spec::Matchers::Change を使うと、一連のコード(proc)実行時に変化したこと(仕様)を簡単に記述することができる。 should change(receiver, message, &block) should change(receiver, message, &block).by(value) should change(receiver, message, &block).from(old).to(new) should_not change(receiver, message, &block)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Adventures with Auto-Generated Tests and RSpec
はてなブログ | 無料ブログを作成しよう
http://twitter.com/t_wada/status/2273346230