RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明🖥 VULTRおすすめ 「VULTR」はVPSサーバのサービスです。日本にリージョンがあり、最安は512MBで2.5ドル/月($0.004/時間)で借りることができます。4GBメモリでも月20ドルです。 最近はVULTRのヘビーユーザーになので、「ここ」から会員登録してもらえるとサービス開発が捗ります！
【Rails】Turnip + RSpec + Capybara + Selenium でエンドツーエンドテスト - Qiita
RailsでTurnip + RSpec + Capybara + Seleniumを使ってエンドツーエンドテストを書いていこうと始めてみたので方法をメモしてみます。 今回はエンドツーエンドテストをして失敗したところや詳しくテストしていきたいところに関してユニットテストを書いていく感じにしようと思ってます。 Turnipでシナリオを作成して、RSpec,Capybaraで実際にブラウザを操作しながらテストしてく感じだと思います。その際Capybaraでスクリーンショット撮ったりしながら進めます。 設定 まずは今回使用したgemたちです。 group :development, :test do gem 'rspec-rails', '~> 3.1.0' gem 'factory_girl_rails', '~> 4.4.1' gem 'capybara', '~> 2.4.3' gem '
使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
Rspecの文法の基礎 - Qiita
describe <クラス名> do it "<期待する動作の内容>" # ... end context "<条件の内容>" do it "<contextの条件下で期待する動作の内容>" do # ... end end end ここで、 contextは、describeに置き換え可能 itは、specifyまたはexampleに置き換え可能 なので、文脈に合わせて使いやすい用語を使えば良い。 なお、デフォルトの設定では、名前として<クラス名>_spec.rbというようにサフィックスとして_spec.rbがないとrspecコマンドで全体を走らせた時に無視されるようになるので気をつけること。 何をしているか describe,contextはExampleGroupを生成 it,specify,exampleはExampleを生成 なお、topレベルのdescribeはExampleG
今日から使える！RSpec 3で追加された8つの新機能 - Qiita
はじめに RSpec 3が正式リリースされて2ヶ月ほど経過しました。(正式リリースは2014年6月) ネットの情報を見ていると、これまでは「既存のテストケースをRSpec 3にアップグレードさせる方法」や「RSpec 3で削除されたり、記法が変わったりした点」など、「守りの姿勢」に入った情報が多かったように思います。(僕自身もそういう情報をたくさんアップしていました) しかし、RSpec 3では以前のバージョンでは使えなかった新しい機能も数多く導入されています。 そこで本記事では「攻めの姿勢」で「RSpec 3から導入された新機能」をまとめてみました。 なお、ここでフォーカスするのはテストコードの書き方にダイレクトに関わってくるマッチャの新機能です。 2015.01.12：RSpec 3.1に関する情報を追記しました RSpec 3.1に関する情報も追記しました。 もともと紹介していた新機
RSpec - Relish
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の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).
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
