RSpec: Overview
Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel
「RSpec 2からRSpec 3へ移行する方法」を発表してきました #rubykansai - give IT a try
2014.05.23 追記: 移行の方法は電子書籍でも説明されています 僕が翻訳を担当している「Everyday Rails - RSpecによるRailsテスト入門」という電子書籍でもRSpec 3（厳密にはRSpec 2.99）へ移行する方法を説明しています。 詳しくはこちらのエントリをご覧ください。 RSpec 3 へバージョンアップする準備を始めよう！「Everyday Rails - RSpecによるRailsテスト入門」の改訂版をリリースしました - give IT a try はじめに 昨日(2014年3月29日)、Ruby関西主催の「Ruby/Rails勉強会@関西 60th」で「How to upgrade your Rails application to RSpec 3」というタイトルの発表をしてきました。 カッコつけて横文字で書いていますが、簡単に言えば「RSpec
「RSpecをもっと理解したかったので、まとめを作りました」に感動してRuby 1.9.3でやってみた！
🐰 目次(1)RSpec はじめの一歩 (2)stackクラスとstackクラスのRspec (3) before/after (4) matcher（マッチャ） (5) カスタムマッチャ (6) サンプルソース(GitHub) 🎂 (1)RSpecはじめの一歩we use RSpec to #describe Behaviour of a system using Examples of how #it should work. 「#itがどのようにworkするか」を例にして、システムの 振る舞い(動作)を説明するためにRSpecを使う From [Ruby][Rails] RSpec をもっと理解したかったので、まとめを作りました RSpecの導入の説明には一番マッチします！ 🚕 (2)stackクラスとstackクラスのRSpec次のstackクラスをテスト対象とします。 cl
RSpecで、Cucumberのような結合試験のspecを記述する - 高尾宏治日記 on はてな
Cucumberって、仕様設計者の意図をプログラムによる自動テストにできる魔法です。 仕様設計者っていうのは、Rubyでのプログラミングが難しいけど、お客さまのニーズを理解して、それをドキュメントにできるハイパーな人です。プログラマにとっては神様です。 （でも、それがプログラマの徹夜の源なのだったりしますよね。実現が困難で意図が不明な仕様を必死で実装する感じですよね。だから、それをなんとかしなければ徹夜は解消できないと考えてみました。） Cucumberではプログラマ以外の人でも分かりやすい記述ができます。 でもね、どうせそのドキュメントを見るのはプログラマだけです。なので、生のCapybara APIで十分なのかもしれませんね。なので、ここではRSpecのfeature specを考察します。 from Feature spec on Relick : https://www.relis
ちゃんとテスト書き始めた話 - AnyType
テストのモチベ＝怖いからやる 正直に白状すると、「これまでテスト書いたことない && 会社にテストの文化がない && テスト書いてる時間ない」っていう状況で、時間を割いてでもテストを書こうっていうモチベがなかなか湧かなかった。 そんななか、唯一、ハッキリとしたわかりやすいモチベは「デグレが怖い」という恐怖心から解放されることだった。 プロジェクトが大きくなるほど、自分が書いたコードがどこまで影響するか把握できなくなってくる。だからといって、変更のたびにブラウザでポチポチ一個ずつ確認する作業はだるい。 テストが通ってるという事実が抜群の安心感をもたらすことがわかってきて、ちゃんとテストを書くようになったというお話です。 500返ってないか怖い 一番わかりやすいテスト項目として「ユーザーにエラー画面を表示していないか」というのがまずアタマに浮かんだ。 モデルとか変更すると、影響範囲よくわからな
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
Let's Try 受入テスト [16] - オブログ
こんにちは、家永です。 本連載は、Acceptance Testingをテーマにし、今日は、turnipを学習します。 Turmip Turnipは Gherkin(Given When Then)形式でテスト記述することできる、プログラマー、テスター、顧客向けの BDDフレームワークです。Cucucumber とは異なって、RSpec拡張で実行される、正規表現の代わりにプレースホルダーを使ってステップファイルを簡潔に記述できる、同一のステップ名でも異なるステップ実行が指定する方法を提供している等の特徴があります。 https://github.com/jnicklas/turnip/ サンプル 下記にサンプルを作成しました。 https://github.com/haru01/turnip-sample cuke 同様に、featureファイルと stepファイルを用意します。 feat
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, factory_girl, spork, guardによる自動テスト環境の構築 - AnyType
こちらの記事を参考に自分で自動テスト環境を構築した記録です。この記事はすごく参考になりました。感謝です。 Rails3+RSpec2+Spork+Guard(guard-rspec,guard-cucumber)で最速のBDD(振舞駆動開発)環境を作る - Curiocity Drives me ０．環境 # Gemfile source 'http://rubygems.org' gem 'rails' gem 'rake', '0.8.7' gem 'mysql2', '0.2.6' gem 'haml-rails' gem 'jquery-rails' $ bundle install --path vendor/bundle１．rpec-rails, factory_girl_railsのインストール # Gemfile source 'http://rubygems.org' g
Rubyアソシエーション: テスト
ここではRubyで記述されたコードに対するテスト方法の概要について説明します。Rubyには、ユニットテストをしやすくするフレームワーク（ライブラリ）が提供されています。通常は、個々のモジュールやメソッドなど小さな単位で十分なユニットテストを行って検証し、結合テストへと進みます。 提供されるフレームワークは、「テスト駆動開発(Test Driven Development:TDD)」や「振舞駆動開発(Behaviour Driven Development:BDD)」という思想がベースになっています。テスト駆動開発とは、プログラム開発手法の一つで、プログラムに必要な各機能について、最初にテストコードを書きそれが失敗することを確認し（テストファースト）、そのテストが成功するように必要最低限の実装を行った後、プログラムの振る舞いを変えないようにコードを洗練（リファクタリング）していく方法です。こ
Ruby / Rails のテストが約3倍速になって超快適に！！ - 微熱 everyday - subtech
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
RSpec のすごいところ - kなんとかの日記
(注: 以下の内容は、RSpec ユーザの間で広まっていることでもなく、もちろん RSpec 開発チームの公式な見解でもなく、あくまでワシの個人的な見解です。) RSpec のすごいところは、コードに対してではなく仕様に対してテストを書くことを明確にしたことだと思う。何を今さらと言われそうだけど、今さらになってようやく気づいたニワトリ頭ですまんかった。 ワシも最初は、「assert_equal(expected, actual)」のかわりに「actual.should == expected」と書くかっこよさに目を奪われて、テストコードを自然言語に近い形で記述するのが RSpec のすごいところだと勘違いしてたし、それが「TDD (Test Driven Development)」から「BDD (Behaviour Driven Development)」へという新しい潮流だと勘違いしてた
RSpecを日本語の仕様っぽくするには - ナマケログ
今仕事でRailsアプリケーションを組むときに、test/unitじゃなくてRSpecを使ってる。mock周りの使い勝手がいいとか、語彙が馴染みやすいとかいろいろ魅力があるんだけど、その「可読性」を保つにはなかなかコツがいると思う。言うまでもなくRSpecはRubyのコードを「英語の表現として自然に見える」ようにすることを意図して語彙や書き方を決めている。これは英語圏のエンジニアには非常に素敵なことではあるんだけど、英語が苦手で英作文なんて始めて数分で泣きたくなるようなへたれ外国語学部生にとっては正直やっかいだし、周りの人達の大半は英語に慣れていない人達*1だったりするので、せっかく可読性が高い綺麗な表記でさえむしろ意図を理解する妨げになったりする。いっそドイツ語で書いて「お勉強」に活用してやろうかという衝動に駆られたけども、誰一人として読めない上に一週間後の俺ですら理解に苦しみそうなので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.func09.com/wordpress/archives/475
はてなブログ | 無料ブログを作成しよう
はてなブログ | 無料ブログを作成しよう