【翻訳】RSpecのリードメンテナだけど何か質問ある？ - Qiita
はじめに 先日、Redditでこんな記事が載っていました。 AMA: The authors of "Effective Testing with RSpec 3", Myron Marston and Ian Dees : ruby この記事は書籍「Effective Testing with RSpec 3」の筆者であるMyron Marston氏とIan Dees氏が、書籍に関する質問に何でも答えます、という企画です。 この2人のうち、Myron Marston氏はRSpecの開発者（リードメンテナ）です。 Q&Aを読んでいると、RSpecの開発者ならではの意見だなと思うところがたくさんあり、なかなか興味深い議論になっていました。 というわけで、この記事では先ほどのQ&Aから「これは日本のRubyプログラマにも役立ちそう」と思ったやりとりをピックアップして翻訳してみます。 ピックアッ
RSpec で expect した時のログ - いもろぐ
rspecでexpectするときに、「文字列が詰まった配列」を期待していたのですが、 期待と違う文字列が入ってた ("aaa"を期待してたのに"bbb"が入ってた) 期待してない文字列が入ってた (配列の要素数が増えてた) ってことがあって、ログに出力されるdiff見方がよくわからなかったので整理してみました。 # test_spec.rb require 'rspec' expected_data = { match: "title", mismatch: "description" } got_data = { match: "title", mismatch: "description!!", added: "22" } describe 'てすと' do context '配列比較' do it 'できるかな' do expect(got_data).to eq(expected_
Rails tips: RSpecテストを遅くする悪い書き方3種（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 3 things that slow down and make your RSpec tests worse（現在はリンク切れです） 原文公開日: 2018/03/21 著者: Paweł Dąbrowsk 2018/05/01: 初版公開 2023/11/14: 更新 テストが遅くなる原因はさまざまで、コードに関係するものもあればそうでないものもあります。今回は、specを高速化して改善するちょっとした変更のコツをご紹介します。 🔗 1. trueかfalseだけを期待する場合はbe_truthyやbe_falseyを避ける まずは以下のコードをご覧ください。 expect(true).to be_truthy expect(1).to be_truthy expect('string').to be_truthy expe
Railsのテスト実行時間を1/3まで短縮した話 (Rspec + CircleCI)
背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。 業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。 おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。 こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して
Introduction · rspec-style-guide
RSpec スタイルガイド これはなに 可読性の高いテストコードを書くためのお作法集です。 みんなの意見を取り入れることでより良いガイドにしていきたいと思っているので、次に当てはまる場合はどんどんIssuesやPull Requestを送ってください。 疑問に思う点がある ここに書かれていないお作法がある 内容はいいけど表現がおかしい もっといいサンプルコードがある English Version 前提 RSpec FactoryBot describeとcontext describeとcontextは同じメソッドだが、次のように使い分けることで何をテストしているのかをわかりやすくできる。 describe の引数にはテストの対象を書く context の引数にはテストが実行される際に前提になる条件や状態を書く 例 RSpec.describe Stack, type: :model d
Rspecのshared_context基礎の基礎 - Qiita
調べようと思った最初のきっかけは、Rakeタスクのテストを調べていて見かけたこの記事。 shared_context ??? な状況だったので、その場はそっ閉じ。 翌日、業務でのコードレビューでテストコードのリファクタを考えていたところ、再び shared_context をキーワードで見かけたので、今日のテーマとする。 shared_contextの用途 名前のとおりですが、テストにおける条件(=context)を共有するために用いる 使い方 Rails 4.2.4 RSpec 3.3.0 その1 人(Person)のモデルがあり、年齢を保持している。 20歳以上であれば、喫煙可能 20歳以上であれば、飲酒可能 20歳以上であれば、投票可能 ※選挙権引き下げられてるよ というツッコミはなしで。。。 ○ Person モデル class Person attr_reader :age de
RSpec 3.5 がリリースされました！
Sam Phippen, Myron Marston, Jon Rowe and Yuji NakayamaJul 1, 2016RSpec 3.5 がリリースされました！ 私たちは semantic versioning に準拠する方針を掲げているため、 このリリースはすでに RSpec 3 を使っている方にとってなにか対応が必要になるものではありません。 しかし、もし私たちがバグを作り込んでしまっていた場合は教えてください。 できるだけ早く修正をし、パッチ版をリリースします。 RSpec は世界中のコントリビュータと共に、コミュニティ主導のプロジェクトであり続けます。 今回のリリースには、50 人以上のコントリビュータによる 600 以上のコミットと 150 以上の pull request が含まれています！ このリリースに向けて力になってくれたみなさん、ありがとう！ 主要な変更 C
RSpec の feature spec でヘッドレス Chrome を使う - Speee DEVELOPER BLOG
Speee エンジニア組織推進室の服部 (yhatt) です。 みなさん E2E テストされていますでしょうか。弊社の Ruby on Rails プロダクトにおいては、RSpec、Capybara、 Poltergeist を組み合わせ、 feature spec で E2E テストを行う構成が一般的でした。 そんな中、Chrome 59 に ヘッドレスモード (--headless) が搭載 されたことで、テストや CI 環境において、最新の Chrome 環境による E2E テストを実施できるようになりました。それに合わせて、PhantomJS のコアメンテナーがメンテナーを降りる ことを発表し、PhantomJS のアップデートや、継続的サポートは期待できない状況となっています。 ヘッドレス Chrome ことはじめ | Web | Google Developers [A
【初心者向け】レビュワーをイライラさせるRSpec集と解決方法 - メドピア開発者ブログ
こんにちは。メドピアにjoinして3ヶ月目の保立です。 毎週のように新しい開発が進むため、毎日楽しくソースコードを書かせてもらっています。 テストコードを制するものは、Railsを制す!!! ということで、今回はメドピアのRSpecについてです。 メドピアでは、RSpecを用いてテストコードを書いており、 - 1) models配下に記載するビジネスロジックに対するUnitTest - 2) 機能ごとのEndToEndTest (E2E Test) の2種類のテストコードを書いています。 RSpecについて、書こうと思ったきっかけ RSpecは（というかRuby自体が）様々な書き方で動かすことができるため、統一したルールがないと、書いた人によってバラバラなテストコードになります。 私も初めてRSpecを書いた際に、参考書やソースコードによって書き方がバラバラで、どのRSpecを参考にすれば
RSpecを並列実行するgemを作っている話 - Qiita
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
RspecでJSON形式のハッシュをFactoryGirlなどで用意したデータでテストする際に使えるCustomMatcherを作った。 - Qiita
で動作確認済み。 はじめに(具体例) RailsでAPIを作成した際のJSON形式のハッシュのテストに使えるRspecのCustomMatcherになります。 下記のようにJSON形式のハッシュのテストを書くことができます。 tests_controller.rbがあるとします。 ・JSON形式のハッシュのkeyとvalueの一致のテスト(key順不同でOK) #match_hash_after_jsonalized # subject:テストしたいJSON形式のハッシュ。ここでは # {name => 'Name', description => 'Description'} # # data:テストするために用意したハッシュ。ここでは # {name => 'Name', description=> 'Description', # created_at => '*****', upd
俺のRSpecがこんなに雑なわけがない - Qiita
ここ最近、 RSpec の書き方が自分の中で変化したので、そのことを書きます。（こういう話ちょっと今更なきもしますが...） 私の書き方は少数派だろうと思います。他の人に強く勧めるつもりもありません。 ただ、どうにも Better Spec のような書き方には疲れました。 テストを書くということはもっと気楽なものでいいように思います。 こういう書き方もあるんだよ、という程度で読んでもらえれば幸いです。 概要 ほんの一年くらい前まで Better Spec みたいな RSpec の書き方を私も心がけていました。 describe と context を使い分け、subject と it をうまいこと組み合わせてテストを作っていました。 簡単な例ですが、次みたいな感じです。 # 以下、このテストを「ケースA」と呼びます。 describe 'Book' do describe '#valid?
体育の日って高速に唱えるとテストの日に聴こえる - ✘╹◡╹✘
テスト書きすぎ問題 - hitode909の日記 階層が増えるとテストが増える - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 最近書いているWebアプリは、HTTPリクエストを送ってレスポンスと状態をテストする、というテストだけ書くようにしてる。リクエストするとブログエントリを返す、というサービスだとこういう風なテストを書いてる。(HTMLを返すようにすると話が広がって説明が面倒なのでJSONを返すAPIで説明する) describe "Entry resource" do let(:params) do {} end let(:env) do { "HTTP_AUTHORIZATION" => "Bearer: #{access_token.token}" } end let(:access_token) do AccessToken.make(user
RSpec Testing for Beginners, Part 1 | Envato Tuts+
Are you new to Rails? New to coding? Curious about RSpec and how you can start testing? If so, this article should be a good starting point for you to get into test-driven development. It will explain to you the why and the how, and it will give you a survival kit to go on your first testing spree. Topics What’s the Point? RSpec? Getting Started Running Tests Basic Syntax Four Phases of Tests The
RSpec で Kernel.open をスタブする - Qiita
class HidamariController < ApplicationController # POST /hidamari/sketch def sketch ### 略 ### open('http://www.tbs.co.jp/anime/hidamari/') ### 略 ### end end 上記のように open-uri の Kernel.open を使用しているコードがあります。 その単体テストで open が呼ばれることを確認したいです。 うーん、Kernel.open をスタブする方法がぱっと思い浮かばなかったので色々試してみました。 # NG expect(Kernel).to receive(:open).with('http://www.tbs.co.jp/anime/hidamari/') # OK expect_any_instance_of(Kern
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
stub_const overwrites Class definition · Issue #1079 · rspec/rspec-mocks
移動しました - SmartHR Tech Blog
VCRを使うとRSpecのWebmockの作成が超絶楽になった！
GitHub - natritmeyer/site_prism: A Page Object Model DSL for Capybara
RSpec Testing for Beginners, Part 2 | Envato Tuts+
