私がRSpecを書く場合のやり方について | 自転車で通勤しましょ♪ブログ
今日は木曜日だったので、ハンバーグの会（Okayama.rb）に参加してきました。 今日は@mako_wisにテストの書き方について相談を受けたので、粒度とかについて説明しましたが、私は説明し始めると早口になってしまうので詰め込みすぎたかもしれないと思ったのでちょっとまとめておこうと思いました。ちなみに、書き方といってもRSpecの始め方とかではないです。その点はあしからず。 Railsプロジェクトのいいところは、テストがとてもしやすいところだと思います。 私は今の会社に入るまで、テストは書きたいけれど、どう書けばいいのかわからなかったのと、頑張って書いてみたものの、成果が周りに評価されなかったのでこのままでいいのだろうか？と思い悩んでいました。しかし、既にテストがあるプロジェクトに入って書き方を学べた事と、同僚とThe RSpec Book読書会を社内で開いて勉強したおかげで、結構綺麗に
RailsのRESTful APIをテストで理解する - ワザノバ | wazanova
http://www.commandercoriander.net/blog/2014/01/04/test-driving-a-json-api-in-rails1 comment | 0 pointsPivotal LabsのEno ComptonがRailsでJSON APIをテスト形式で理解できるように紹介してくれてます。「Railsアプリをてがけると、いずれ、シングルページアプリ、モバイルクライアントのためにRESTful APIが必要になるだろうから練習用に。」ということで、コードはGithubで公開されています。 GET /movies POST /movies GET /movies/:id PUT /movies/:id DELETE /movies/:id 上記のrouteをサポートするために、Railsアプリ + RSpec + FactoryGirlを用意したら、
RSpecのshouldはもう古い！新しい記法expectを使おう！
というように書くようになりました。 別にshouldを使った記法がなくなったわけではありませんが、 https://github.com/rspec/rspec-expectations のREADME.mdには、もう新しいSyntaxの説明しか載っていないし、今後はexpectの方を使っていくほうがいいでしょう。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax には、新しいSyntaxを導入した背景が説明されています。 簡潔に書くと、shouldだとBasicObjectを継承したクラスのテストを書くときに不具合が起こるみたいですね。 移行方法 基本 基本的には、上に書いたように、 foo.should を expect(foo).to に foo.should_not を expect(foo).
RSpecの構文 - Start! Ruby
* RSpecの構文 見本は、これ http://github.com/mitim/tddbc-lrucache/blob/master/lru_cache_spec.rb ** 慣習 RSpec用のテストとして書くテストコードは、[テスト対象のファイル]_spec.rb という名前でつくる。 ** なにはなくともrequire require 'lru_cache' テスト対象のファイルを読み込ませる。 ちなみに、RSpecの何かをrequireする必要なない。 ** まずは基本 describe do end で、一番外側のブロックを記述する。 通常は、次のようにテスト対象のクラスを宣言しておく。 describe LRUCache do end また、一緒に説明を付けることも可能。 describe LRUCache, "を初期化する場合" do end もちろん、説明だけにすること
RSpec 3に向けての計画(日本語訳) - 有頂天Ruby
Myron Marston » The Plan for RSpec 3の微妙訳です。(翻訳最中なう)だいたい翻訳しました。訳がうんこなのは勘弁(ご指摘いただけると助かります)。 2013/7/23 21:25 id:kakutani さんのツッコミをもとに、誤訳等を修正しました。ありがとうございます(〃･ิ‿･ิ)ゞ RSpec 3に向けての計画 RSpec 2.0は2010年10月にリリースされました。 リリースされてから今までの3年間、後方互換性を保ったままRSpecを継続的に改善してきました。 しかし、RSpecの2.xより古いリリースとの後方互換性を保つために残しているひどいコードの蓄積は限界点に達しています。 RSpec 2.14はRSpec 2の最後のリリースになるでしょう(今後も多分bugfixのリリースすることはあるでしょう)。 我々はRSpec 3に取り掛かっています、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.inouetakuya.info/entry/2013/12/28/205008
http://blog.inouetakuya.info/entry/2013/10/27/200111