Thorでタスクを書くとそのメソッドが普通のRubyのようには呼べません。 それでもやっぱりテストは書きたいのでThorのspecをいろいろ見てたらありました。 # encoding: utf-8 require "rubygems" require "thor" require "rspec" require "stringio" class Sample < Thor desc "name", "sample name" def name puts "pochi" end end describe Sample do it "should display 'pochi'" do capture(:stdout) { Sample.new.invoke("name") }.strip.should == "pochi" end end
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回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入
Writing ‘good code’ is always a challenge for every project. Unfortunately, we always associate it with development and not tests. What about automation test code? Ever notice that you have write more automation code than the actual lines of development code? Improper automation code leads to slow running specs, huge LOC in your spec files and a whole lot of confusion when you open a spec file. So
2014.2.7 追記: 日本語版を発売しました！ 「この本は英語版しかありません」と書いていましたが、僕自身が日本語版の翻訳し、Leanpubから発売しました。 詳しくはこちらのエントリをご覧下さい。 RSpec初心者必読！「Everyday Rails - RSpecによるRailsテスト入門」を発売しました - give IT a try 正式版公開のお知らせと幻のあとがき・Everyday Rails - RSpecによるRailsテスト入門 - give IT a try はじめに 先日、RSpec関連のこんな電子書籍を買いました。 Everyday Rails Testing with RSpec Kindleに入れて読みました。 RSpecを学習するための書籍としてはなかなか良かったので、今回はこの本の内容を紹介します。 この本を購入した動機 RSpecは仕事でも使っていて、
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に取り掛かっています、
Myron’s blog post does a fantastic job explaining why this is better. To summarize: RSpec does not own every object in the system, so it cannot add the should and should_not methods to every object. This can lead to some really confusing errors. Using expect works around this. Block expectations already used the expect syntax out of necessity. The inconsistent syntax made it harder to read specs t
Rubyの試行錯誤支援・テスト支援ツール。 「# =>」という注釈記号を入れた行に式の値を注釈したり、Test::UnitのassertionやRSpecのexpectationを自動で入れてくれる便利なツール。 rcodetoolsパッケージに入っていて、RubyGemsパッケージがあるので、「gem install rcodetools」でインストールできる。 READMEより… a, b = "foo", "baz" a + b # => a.size # => これを「xmpfilter」にかけると、 a, b = "foo", "baz" a + b # => "foobaz" a.size # => 3 こうなる。 Test::Unitでは、 def test_insertion @o.insert "bar" @o.insert "baz" @o.size # => @o.l
いちごジャムを煮る季節 商店街の八百屋でいちごが安くなっていて、「あ、もうそんな季節」と思った。個人的な〈いちごジャムを煮る季節〉の到来条件は、以下の三つが揃うことであり、今年も無事に「シーズン開幕」の判定となった。 ・１パック300円以下・小粒ぞろいのパックであること・密封…
■ [rspec][ruby][rails] rspec-rails と capybara のまとめ rspec-rails と capybara をアップデートしたら request spec で click_link が使えなくなったという声を隣席のぱーらー氏方面から聞こえてきたので、ちゃんとコードを読んで新人's に展開しました。 ぶっちゃけ spec_helper.rb で include Capybara::DSL してしまえば動くんですが、rspec や capybara という Rails でテストを書く上で無くてはならないライブラリの間でどのような方法が良いということになったのかを知ることは Rails Way に乗る上で大事なことです。 それぞれがどのように動いているかを理解するにはまず最初に example group というものを読むと理解が進みます。 https:/
![[rspec][ruby][rails] rspec-rails と capybara のまとめ, [Life] 散髪記録 - HsbtDiary(2012-11-16)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
Stability can become an issue as web applications evolve and grow – integration tests provide a great way to perform end-to-end tests that validate the application is performing as expected. Integration test with RSpec and Capybara When writing integration tests, try to model the test around an actor (user of the system) and the action they are performing. # spec/features/visitor_signs_up_spec.rb
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
RSpec の DSL には、 example と言うメソッドがあり、そこを経由して現在実行中の example の情報を得ることができる。 def add(*args) args.inject(:+) end describe "add" do before do p example.class #=> RSpec::Core::Example end subject { add(*args) } context "when 1 + 1" do let(:args) { [1, 1] } it { should == 2 } end end 具体的には、 example は RSpec::Core::Example のインスタンスらしい。 Class: RSpec::Core::Example 以下のような属性、メソッドがある： #exception 実行中の example で最初に起
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
RSpec 簡潔に記述する(1) it ブロックを短く書く！
コード比較 旧 describe User do it "should be instance of User" do Factory.create(:user).should be_instance_of(User) end it "should belongs to Guild" do Factory.create(:user).guild.should be_instance_of(Guild) end describe "#add_exp(experience_point)" do it "should not raise error" do lambda{Factory.create(:user).add_exp(10) }.should_not raise_error end end describe "::get_list()" do it "should be instan
RSpecの話です。 RSpecは、テストコードがそのまま仕様を記述するドキュメントになる、というのが大きな利点の一つです。 しかし、rspecコマンドに-dオプションを渡して出力されるドキュメントは、必ずしも読める文章になっているとは限りません。 例として、以下のようなCanCanのspecを見てみます。 require 'spec_helper' require "cancan/matchers" describe Ability do context 'an user' do let(:user) { Factory.create(:user) } let(:article) { Factory.create(:article) } let(:own_article) { Factory.create(:article, :user => user) } subject { Abil
rails3 RSpec.configure do |config| config.before(:each) do I18n.locale = :ja end end
こんにちは、ほりいです。Asset Pipeline に感銘を受けている今日この頃です。 今日は社内で RSpec をこれから勉強したいんだけど検索してもよくわからない！と質問を受けたので、読むべきエントリをまとめてみました。 ＃ 現状ぐぐると RSpec.info がまず出てくるけどもう更新されてないっぽいので優しくないんですよね…… h2. これは読んでおこう！ h3. スはスペックのス * “スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)”:http://jp.rubyist.net/magazine/?0021-Rspec * “スはスペックのス 【第 2 回】 RSpec on Rails (コントローラとビュー編)”:http://jp.rubyist.net/magazine/?0023-Rspec 内容は若干古いのですが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
