Help us understand the problem. What is going on with this article?
TDDでRSpecを書くにあたって、どれだけ効率的に効果的なテストが書けるかは、品質を高めていく上ですごく大切なことだと思います。 今回、RSpec3用のドキュメントやWebサイトをいろいろ読みなおして、最近までに特に良かった記事などを中心にまとめ直しました。 RSpec3に入門しようとしている初心者さんや、普段使っているけどもう一度RSpec3の知識を整理したい人にオススメのマトメです！ 🗽 TDD/BDDとは？TDD/BDDにおける「振る舞い」の意味するところとは何なのか RSpecに限定された記事ではないですが、BDDの根本的な概念の「振る舞い」についてまとめられた記事です。 これを知っておくことで、ここから先の話がかなりスムーズに理解できるようになると思います。 🎂 まずテスト書いてからコード書くシンプルなチュートリアルはじめてのRSpec - まずテスト書いてからコード書くシ
ネクストでレコメンドエンジン開発をしてる古川です。 rubyで、ファイルを読み込んで加工して別のファイルに出力というプログラムをよく書きます。 最近、rspec でテストを書くようになったのですが、beforeでテスト入力ファイルを作成し、 after で作成したテスト入力ファイル、テスト出力ファイルを削除、ということをしていました。 とりあえずは、これで問題なかったのですが、同時実行時や、実行時パス、パーミッションなど、 今後いろいろ問題になりそうで、いやだなと思っていたところ、Stack Overflowに、 まさに、それがやりたかったんだよ！という記事を見つけました。 StringIOを使えばよかったのですね。 記事は、読み込みテストだけでしたので、書き込みテストも追加してみました。 テスト対象クラス my_file_io.rb class MyFileIo def run(path
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
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供する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ってわけわからん」となっている人もこの記事で再入門してみると
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
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0064 号 バックナンバー Rubyist Magazine 0064 号 Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist
コントローラもテストしてみる。 ページにアクセスしてサクセスが返ることと、期待するテンプレートを表示することを確認するシンプルなケース 画面にアクセスするのは get :アクション名 成功が返るのは response.should be_success テンプレートの表示判定は response.should render_template("XXXX") describe '登録画面にアクセスしたら' do before do get :add_index end it 'サクセスであること' do response.should be_success end it '登録画面を表示すること' do response.should render_template("tunes/add") end end フォームからデータを送信したケースのテスト post でアクションに対してパラメータ
2013年08月22日13:26 Ruby factory_girl で最低限知っておきたい4つの使い方 みなさん、テストを書くときには Fixture Replacement として何を使ってますか？一番メジャーなところだと factory_girl でしょうか。machinist も有名ですね。シンタックスの違いのようなので基本的にはどちらでも良さそうです。 参考（stackoverflow）Machinist vs FactoryGirl - pros and cons In other words, both are extremely similar, just with a different default syntax. 今回は（僕が factory_girl4.2.0 を使ってるので）factory_girl4.2.0 についての話です。 インストール まずインストールし
Fixture suck! と言われて久しいですね。こんにちは！ onk です。 最近は Rails 3.0 でソーシャルアプリを作っています。で，BDD に RSpec 2.0 ＆ FactoryGirl を使い出したので FactoryGirl についてご紹介。 define まず，FactoryGirl は ActiveRecord に依存しています。factory の定義は AR のモデル単位。 Factory.define :onk, :class => User do |user| user.name "onk" user.email "onk@drecom.co.jp" end たとえばこんな感じですね。 create / build 定義した factory を使うときは Factory.create(:onk) #=> #<User id: 1, name: "onk",
このエントリでは，Ruby on Rails （以下 Rails）の ActiveRecord モデルテストについて，1) どこの何をテストすればよいか，2) どのようにテストを書けばよいか，のガイドラインを示します．このガイドラインは Rails 公式のものではなく，id:passingloop が使っている私的なものです．疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします． はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです．Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります．しかし，「どこをどうテストすればよいのか」についての解説は，「使い方」の解説と比較して少ないように思います．もっとも，テスト一般についてどう書くかはアプ
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
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入門記事として、和田卓人さん(@t_wada)の「RSpec の入門とその一歩先へ」という記事があります。 僕もRSpecを全く知らなかった頃に参考にさせてもらいました。 今読んでもとても素晴らしい資料なのですが、RSpecのバージョンが古く、現状の書き方とマッチしなくなってきているのが少しもったいないところです。 そこで、この記事では和田さんの記事をRSpec 3バージョンに書き直してみようと思います。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション(本記事) 第2イテレーション 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter1 本記事のライセンスについて 本記事は クリエイティブ・コモンズ 表
技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの
みなさんはこんなふうにRailsアプリケーションを作ったことはありませんか？たとえば、ブラウザをポチポチとクリックするだけでテストを終わらせて「たぶん大丈夫」と思い込んだり、「とにかく全部うまくいきますように」とただ祈るだけだったり……。 心配しないでください。それは誰もが通る道です。アプリケーションのテストやテスト駆動開発はRails開発における重要なトピックですが、巷の参考書を見ると適当な説明で済ませているものも多かったりします。本書「Everyday Rails - RSpecによるRailsテスト入門」では、どのようにして私がそうしたテクニックを身につけたのか、そして、どのようにしてコードの信頼性を上げ、ブラウザ上で延々とテストしなくて済むようにしたきたのかをみなさんに説明します。 対応バージョンについて2024年1月のアップデートで、本書のコンテンツをRails 7.1とRSpe
SaaSのCIと言えばTravis CIやCircle CIといったサービスが有名ですが、いずれにしてもプライベートリポジトリを使う場合は有料なのです。しょうがないよね、商売だもんね。でもCI入れたいなぁ。 そんな中、GithubだろうがBitbucketだろうがプライベートリポジトリでも無料で使っていいよ！というβ期間中のCI、Werckerが僕の周辺で話題になっていたので、触ってみました。画面もスゲー使いやすい上に、ハマりどころもなく、これはひょっとしてひょっとするんじゃないの？という期待を込めて、rails newからRailsアプリをHerokuにデプロイするまえのチュートリアルを作ってみました。みなさんもこの記事を参考に、ぜひ使ってみてください。 この記事のゴール Githubにpushしたら自動的にWercker上でRSpecのテストが動くこと Werckerでのテストに成功し
この記事はRuby Advent Calendar 2013の6日目の記事です。 昨日はShindo200さんのRuby で paiza.jp のオンラインハッカソン問題に挑戦するときに少し役に立ちそうなことでした。 概要 Rubyのデファクトスタンダードなテストフレームワークと言えるRSpecですが、現在バージョン3.0のリリースへ向けて開発が進められており、先日2013年11月8日には3.0.0.beta1がリリースされました。 この記事ではRSpec 3における変更点と、RSpec 3へのアップグレード手順、また既存のspecを最新の記法に変換するツールを紹介します。 追記 RSpec 3は2014年6月2日に正式リリースされました。この記事は2013年12月6日に書かれたものですが、正式版においても通用する内容になっています。 正式版における主要な変更点は、以下のページが参考になる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く