使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
Jenkinsとrrrspecと私 - 弥生開発者ブログ
Misoca開発チームの黒曜(@kokuyouwind)です。 最近PS VRを買いました。画像は夏にSony StoreのPS VR体験会へ行った際、スタッフの方が撮ってくださった写真です。 OculusやViveと比べると解像度は低めですが十分な没入感がありますし、なによりアイマスやVOCALOIDなどのキャラクターコンテンツが色々あるのは強いですね。 PS VRはいいぞ。 rspec-queueからrrrspecへの移行 MisocaではJenkinsを使ってCIを回しています。 またrspecでテストを書いており、Jenkins上では時間短縮のためにrspec-queueを使って並列実行していました。 しかし、テストが増えるにつれてrspecの実行時間が長くなってしまい、CPUコア数やメモリの制約で1ノード内での並列数も限界になっていました。 このため、ビルド時間の短縮を目的にrr
手作業で構築した AWS リソースの管理には awspec が良いと思ったのでメモ - ようへいの日々精進XP
tl;dr 手作業で構築した AWS リソースの管理には以前から気になっていた awspec が良いと思ったのでメモ。 二台、三台のインスタンスなら...とうっかりと手作業で構築したインスタンスや、どんな設定で作ったか判らないけど、なんとなく利用されている S3 Bucket の管理をどうしようかなと思っていたら awspec の generate コマンドがリソース情報を生成してくれるので試してみた。 参考 github.com qiita.com memo インストール $ cat Gemfile source "https://rubygems.org" gem 'awspec' gem 'rake' $ bundle 初期化 $ bundle exec awspec init + spec/ + spec/spec_helper.rb + Rakefile + spec/.giti
RSpecによるユニットテストの書き方 – recompile.net
最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめに ごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと、次のようなテンプレー
[Ruby on Rails]FactoryGirlによるテストデータの準備 | DevelopersIO
はじめに RSpecを使ってテストを記述している際、テストの実行前にデータをテーブルに登録しておきたいケースが多々あるかと思います。RSpec内でActiveRecordを使ってデータを登録することもできますが、複数のテストケースで同じデータを使いたい場合、データの定義は一箇所で行いたいところです。 この様な場合、Factory Girlを使用すると、一箇所でテストデータを定義できます。今回はこのFactoryGirlの使い方について書きたいと思います。 使い方 使い方の大まかな流れとしては、 FactoryGirlが使用できるようにする 定義ファイルにデータを定義する 必要とするテストケースにてファイルを読み込み、データを適時加工して登録する という感じとなります。尚、この定義したデータを「Factory」とも言います。以下、手順です。 1.Gemfile Gemfileに以下を記述し、
![[Ruby on Rails]FactoryGirlによるテストデータの準備 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4ba9673af464883e264d1d320af2d2947fae03d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F11%2Frails.jpg)
RSpec 3の重要な変更 - 有頂天Ruby
Myron Marston » Notable Changes in RSpec 3の雑な訳です。 誤訳・雑すぎる訳がありましたら、Twitterで@nilp_までご連絡頂けると助かります。 RSpec 3.0.0 RC1が2日前にリリースされました、そして最終的な3.0.0のリリースが目前に迫っています。 我々はβ版をここ6ヶ月にわたり使ってきました、我々はそれらを皆さんと共有できることにわくわくしています。 これが新しいとこだよ: すべてのgemたちにわたって Ruby 1.8.6と1.9.1のサポートがなくなりました これらのバージョンのRubyはかなり前に寿命を迎えました、RSpecはこれらをサポートしません。 Ruby 2.xのサポート向上 最近のRSpec 2.xのリリース(すなわち2.0がリリースされたあと出たやつ)はRuby 2を公式にサポートしています、しかしRSpec
RSpec 3の新機能: コンポーザブルマッチャー - 有頂天Ruby
Myron Marston » New in RSpec 3: Composable Matchersの訳です。 あかんところあったらTwitterで@nilp_までお願いします RSpec 3の、最も大きな新機能が3.0.0.beta2で公開されました: コンポーザブルマッチャ(組み合わせ可能なマッチャー)です。 これにより強力で壊れづらい検証を書けるようになり、新たな可能性が開けました。 例 RSpec 2.xでは、私はこのようなコードを度々書いてきました。 class BackgroundWorker attr_reader :queue def initialize @queue = [] end def enqueue(job_data) queue << job_data.merge(:enqueued_at => Time.now) end end describe Back
Rspecのテスト進捗状況が可視化できるFuubarがいい感じ！ - Qiita
ちょっと不便なRspecのテスト Rspecでテストを書いている人は多いと思うんですが，Rspecのテストちょっと不便じゃありませんか？ 例えばテスト実行中 あとどれくらい残ってるの！？いつ終わるの？(どれくらいのテストが残っているかわからない) テスト落ちたなら，それ先に見せてよ！(どのテストが失敗したかわからない，でも一応最後までテストを実行したい，けど終わるまで結果がわからない) うーん，やっぱりちょっと不便． そんな時に便利なFuubar こちらのビデオを見てもらうとFuubarがどういうものかわかると思います． Fuubarのいいところは 落ちたテストからFaiure/Errorメッセージを出してくれる． 残りのテスト数がわかる 予想終了時間が表示される 素晴らしい！ インストール Fuubarを使うには
Rails4時代の高速テスト環境 Rspec+Guard+FactoryGirl+Spring[NEW!] - Qiita
Rails4時代の高速テスト環境 Rspec+Guard+FactoryGirl+Spring[NEW!]RailsRSpecGuardFactoryGirlspring Railsのテスト環境の定番といえば Rspec Guard FactoryGirl Spork このへんの組み合わせが定番だったんではないでしょうか。 Sporkでテスト環境をプリロードして、Guardでファイルを監視してガンガンテストを回してと。 今回はこのSporkを最近メキメキと頭角を現してきているSpringに置き換えて よりモダンな高速テスト環境の作り方を説明します。 Springのいいところ このSpringなにがいいって、設定がすごく簡単。 おまけにGuard+Rspec以外にもrails generateやrake routesなど他のコマンドも高速化してくれます。 一度体験したらもう戻れません。 必要
![Rails4時代の高速テスト環境 Rspec+Guard+FactoryGirl+Spring[NEW!] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/46aa6f2e659cc914d46b39f41d52f963a99190f6/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9UmFpbHM0JUU2JTk5JTgyJUU0JUJCJUEzJUUzJTgxJUFFJUU5JUFCJTk4JUU5JTgwJTlGJUUzJTgzJTg2JUUzJTgyJUI5JUUzJTgzJTg4JUU3JTkyJUIwJUU1JUEyJTgzJTIwUnNwZWMlMkJHdWFyZCUyQkZhY3RvcnlHaXJsJTJCU3ByaW5nJTVCTkVXJTIxJTVEJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03YWE4YWYyNTA1MzM0ZTNjNjdiZDQ5ODBiZDE4ZmZiMw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwdW5vc2smdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTRkM2IyZDcxNTdjNWMwYzU1ZjBhYWViZmUyMGJjYzQx%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D20084789391f9d573e5af5bbc3e2f9ee)
RSpec の it { … } と速度の話 - Qiita
TDD, BDD にはテストを実行する速度がすごい重要なのはみんな知っていると思うけど、 it { … } 記法が速度にどう影響するか知ってる? という話。 場合によっては、 subject + it, its で何行も並べるより、まとめられるなら 1 つの example にまとめたほうが速いです。 # May be slow describe 'foo' do subject { get :foo } before do # Prepare the model (e.g. FactoryGirl) end it { should be_ok } its(:body) { should match(/foo/) } # ... after do # Clear the DB (e.g. DatabaseCleaner) end end 前提 before や let! でたくさんモデルを
Rubyアソシエーション: テスト
ここではRubyで記述されたコードに対するテスト方法の概要について説明します。Rubyには、ユニットテストをしやすくするフレームワーク（ライブラリ）が提供されています。通常は、個々のモジュールやメソッドなど小さな単位で十分なユニットテストを行って検証し、結合テストへと進みます。 提供されるフレームワークは、「テスト駆動開発(Test Driven Development:TDD)」や「振舞駆動開発(Behaviour Driven Development:BDD)」という思想がベースになっています。テスト駆動開発とは、プログラム開発手法の一つで、プログラムに必要な各機能について、最初にテストコードを書きそれが失敗することを確認し（テストファースト）、そのテストが成功するように必要最低限の実装を行った後、プログラムの振る舞いを変えないようにコードを洗練（リファクタリング）していく方法です。こ
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
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).
るびま
『るびま』は、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 直
RSpec tips - ペンギンラボ Wiki
The RSpec Book を読んで、知らなかった部分のメモが主。 describe / context describe は example group をつくる。example group は 1 つのクラス (RSpec::ExampleGroup::…) として表される。ネストした describe は、外側の example group のサブクラスになる。 describe "root" do it "print ancestors" do p self.class.ancestors # => [RSpec::Core::ExampleGroup::Nested_1] end describe "nested" do it "print ancestors" do p self.class.ancestors # => [RSpec::Core::ExampleGroup:
私はRSpecでテストをこんな感じで書いてる - アジャイルSEを目指すブログ
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
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によるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Serverspec - Advanced Tips
はてなブログ | 無料ブログを作成しよう
