Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 先日、Redditでこんな記事が載っていました。 AMA: The authors of "Effective Testing with RSpec 3", Myron Marston and Ian Dees : ruby この記事は書籍「Effective Testing with RSpec 3」の筆者であるMyron Marston氏とIan Dees氏が、書籍に関する質問に何でも答えます、という企画です。 この2人のうち、Myron Marston氏はRSpecの開発者（リードメンテナ）です。 Q&Aを読んでいると、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第2回です。 今回はRSpecのマッチャについて説明していきます。 第1回と同様、今回も「最低限これだけは」という内容に絞り込んで説明します。 使用頻度の少ないマイナーなマッチャ（注：僕基準）については説明しません。 具体的な項目は以下の通りです。 マッチャとは何か to / not_to / to_not eq be be_xxx be_truthy / be_falsey change + from / to / by 配列 + include raise_error be_within + of これからRSpecを始める人はもちろん、何度かRSpecに触れて「うーん、RSpecってわけわからん」となっている人もこの記事で再入門してみると
RSpec is a Behaviour-Driven Development tool for Ruby programmers. BDD is an approach to software development that combines Test-Driven Development, Domain Driven Design, and Acceptance Test-Driven Planning. RSpec helps you do the TDD part of that equation, focusing on the documentation and design aspects of TDD. Documentation This is the official documentation site for RSpec. Much of the document
はじめに RSpec 3が正式リリースされて2ヶ月ほど経過しました。(正式リリースは2014年6月) ネットの情報を見ていると、これまでは「既存のテストケースをRSpec 3にアップグレードさせる方法」や「RSpec 3で削除されたり、記法が変わったりした点」など、「守りの姿勢」に入った情報が多かったように思います。(僕自身もそういう情報をたくさんアップしていました) しかし、RSpec 3では以前のバージョンでは使えなかった新しい機能も数多く導入されています。 そこで本記事では「攻めの姿勢」で「RSpec 3から導入された新機能」をまとめてみました。 なお、ここでフォーカスするのはテストコードの書き方にダイレクトに関わってくるマッチャの新機能です。 2015.01.12：RSpec 3.1に関する情報を追記しました RSpec 3.1に関する情報も追記しました。 もともと紹介していた新機
Continuing the from the previous post, here is a cheat sheet for RSpec’s assertion library: RSpec::Expectations. RSpec is a mature, feature-packed testing framework, but the documentation can be difficult to navigate. As an alternative to the official documentation, this cheat sheet contains short example code to demonstrate all the built-in expectation matchers. These examples were created with R
def describe_internally(*args, &block) example = describe(*args, &block) cls = args[0] if cls.is_a? Class saved_private_instance_methods = cls.private_instance_methods example.before do cls.class_eval { public *saved_private_instance_methods } end example.after do cls.class_eval { private *saved_private_instance_methods } end end end これを require した RSpec ファイルで、describe の代わりに describe_internally を使
JSON データの POST が Controller Spec で動かない… 最初、テストの性質からしてコントローラーのテスト（spec/controllers/some_controller_spec.rb）に、JSON データを POST するテストを書こうとしました。結果、色んな書き方を試したのですが、どうにも動作しない…。JSON データじゃなくて、パラメータのハッシュを POST する場合は、以下のページの書き方で普通に動きます。 RSpec の ControllerSpec でパラメータとともに post 送信するテスト | EasyRamble ぐぐりまくって調べたところ、次の stackoverflow ページを発見。 As far as I have been able to tell, sending raw POST data is no longer possib
こんにちは、黒曜(@kokuyouwind)です。 最近見つけた面白いポケストップは「シーサーに似た守り神(メイドインタイランド)」です。 PokemonGOは飽きてきて、代わりに最新作のサン・ムーンが欲しくなってきました。 アローラロコンかわいいよアローラロコン。あとミミッキュ。 さて、Misocaに入社して一年弱が経ち、RSpecの書き方にも大分慣れてきたのですが、油断すると冗長で複雑なSpecを書いてしまいがちです。 既存のSpecが複雑だと新しいexampleを追加するときにも書きづらくなってしまうため、気づいたらなるべくリファクタリングするように心がけています。 今回は、最近自分が「こういう書き方だと読みやすく保守もしやすいのではないか」と思っているRSpecの書き方について紹介していきたいと思います。 Specを記述する対象と文脈に着目して分割する 最近書くSpecでは、大体
Ruby Business User Conference 2015での発表資料です。
translations Documentation RSpec is a great tool in the behavior-driven development (BDD) process of writing human readable specifications that direct and validate the development of your application. On the web there are many resources that give complete overview of _what_ you can do with RSpec. But there are fewer resources devoted to how to create a great RSpec test suite. Better Specs tries to
概要 この記事では、RSpecにあまり馴染みがない人にもわかりやすいように、RSpecの理想的な書き方（＝コーディングルール）を説明しようとしています。 書いてあることは個人的な見解です。理性的な議論を歓迎します。 友人に語っているような文体ですのでお気をつけください。 動機 俺はみんなにRSpecを書いてほしかったんじゃない。 いいRSpecを書いてほしかったんだ(´・ω・｀) なぜかバリデーションだけ一生懸命にテストされていて自作の30行近いメソッドにテストがないとか、10行近いbeforeブロックがコピペされまくってるとか、そういうのはさ、見たくないんだ。 あと、http://betterspecs.org/ は読もう。日本語版もあるし。そこに書いてあることはここでは繰り返さないので、あしからず。 総論 はじめに ここから先は読まなくてもいいからこれだけは読んでほしい。 itブロック
Ruby on Railsプログラマーのための「RSpec/Capybara入門」を連載します。Railsを学習中の初心者がテスト駆動開発(TDD)あるいはビヘイビア駆動開発(BDD)を実践するための基礎的な知識や考え方を説明していきます。 メインテーマはRSpecとCapybaraですが、factory_girl、Database Cleaner、Zeusなどの関連するGemパッケージも途中で紹介していく予定です。また、CSSセレクタやXPathについても簡単に解説することになるでしょう。 いちおうRubyとRailsの基礎知識を話の前提としますが、初心者を念頭に置いて丁寧な説明を心がけます。 できるかぎり具体的にコーディングと操作手順を示すつもりです。実際に手を動かしながら読み進めると、より理解が深まるでしょう。 記事一覧 イントロダクション （2013/08/14） RSpec/Ca
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なR
Railsの有名なテストフレームワークのRSpec、エンドツーエンドテスト用のフレームワークのCapybara、エンドツーエンドテストのJavascript(Ajaxなど)部分のテスト用のCapybara-webkitのチートシートです。 基本的な使い方を知っていることを前提に、Railsでの使い方をまとめました。 その他参考になるサイトです。 RSpec/Capybaraの導入方法 FactoryGrilのチートシート 動作確認 Rails 4.1.7 rspec-rails 3.1.0 capybara 2.4.1 capybara-webkit 1.3.0 目次 RSpec Matcher 独自RSpec Matcher RSpec Mock(モック/スタブ) Shoulda-Macher Capybara JSのテスト(with Capybara-WebKit) RSpec Mat
#spec/support/controller_macros.rb module ControllerMacros def login_user before(:each) do @request.env["devise.mapping"] = Devise.mappings[:user] sign_in FactoryGirl.create(:user) end end def login_admin before(:each) do @request.env["devise.mapping"] = Devise.mappings[:admin] sign_in FactoryGirl.create(:admin) end end end # 特殊なところ等、メソッドなど省略しています require 'rails_helper' RSpec.describe Task, :type
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
