【翻訳】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プログラマにも役立ちそう」と思ったやりとりをピックアップして翻訳してみます。 ピックアッ
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 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で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?
RSpec Testing for Beginners, Part 2 | Envato Tuts+
The second article in this short series teaches you how to use various matchers that come with RSpec. It also shows you how to slice your test suite through tagging, how callbacks work, and how to extract some data. We expand a little on the basic survival kit from the first article and show you enough to be dangerous without too much rope to hang yourself. Topics Matchers Let Subjects Callbacks G
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 3.4 がリリースされました！
Yuji NakayamaNov 13, 2015RSpec 3.4 がリリースされました！ 私たちは semantic versioning に準拠する方針を掲げているため、 このリリースはすでに RSpec 3 を使っている方にとってなにか対応が必要になるものではありません。 しかし、もし私たちがバグを作り込んでしまっていた場合は教えてください。 できるだけ早く修正をし、パッチ版をリリースします。 RSpec は世界中のコントリビュータと共に、コミュニティ主導のプロジェクトであり続けます。 今回のリリースには、50 人近くのコントリビュータによる 500 以上のコミットと 160 以上の pull request が含まれています！ このリリースに向けて力になってくれたみなさん、ありがとう！ 主要な変更 Core: Bisect アルゴリズムの改善 RSpec 3.3 では、 実行順序
anonymous controller - Controller specs - RSpec Rails - RSpec - Relish
Use the controller method to define an anonymous controller that will inherit from the described class. This is useful for specifying behavior like global error handling. To specify a different base class you can pass the class explicitly to the controller method: controller(BaseController) You can also disable base type inference, in which case anonymous controllers will inherit from ApplicationC
RSpecでRequest Describer - Qiita
WebアプリケーションのHTTPレベルでの振る舞いに対してテストを記述するとき、皆さんはどのような考えを持ってテストコードを記述しているでしょうか。この投稿では、この手のrequest-specと呼ばれるテストについて考えながら、テストを書くときの幾つかの方針と、RSpec::RequestDescriberを利用してテストコードを簡略化する方法を紹介します。 request-specとは request-specという、HTTPにおけるリクエストとレスポンスの組み合わせを、言わばブラックボックスとして扱うテスト形式の呼び名があります。リクエストを入力、レスポンスを出力として扱い、ある入力に対して期待される出力が返されるかどうかをテストします。rspec-railsの中では、request-specに対して以下の説明が与えられています。 Use request specs to speci
【Rails】RSpecと三種の神器でらくちんWeb APIテスト - Qiita
はじめに 3月頃，『【Rails】RSpecでWeb APIのテストでハマったところ①』という初心者丸出しな記事を書きました． あれから9ヶ月ほど，お仕事としてRailsに触れたりしたため知見・スキルも向上してきたと思います． そして今，前述の記事を見直したところ恥ずかしくて顔を覆いたくなる感じになったので改めてWeb APIのテストについて書いていきます． APIのテスト？ そもそもWeb APIのテストはどこに書くの？ってところからですが… Controller SpecではなくRequest Specに書いていきます． Use RSpec Request Specs Since we’ve established that we’ll be using Rack::Test to drive the tests, RSpec request specs make the most s
実用的な新機能が盛りだくさん！RSpec 3.3 完全ガイド - Qiita
はじめに 2015年6月12日にRSpec 3.3がリリースされました。 APIが大きく変更されたり、派手な新機能が追加されたりはしていませんが、うまく活用するとテストを効率よく書いていけそうな実践的な新機能がたくさん導入されています。 この記事ではそんなRSpec 3.3の新機能を紹介していきます。 新機能一覧 RSpec 3.3で追加された主な新機能は以下の11個です。 これから各新機能の内容を紹介していきます。 特定のエクスペクテーション群をまとめて検証できる（aggregate_failures メソッド） グループやexampleをID指定して実行できる 失敗したテストだけを再実行できる（--only-failures オプション） 失敗したテストを1件ずつ修正できる（--next-failure オプション） テストが増減しても seed を指定したランダム実行が同じ順序で実行
使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
移動しました - SmartHR Tech Blog
RSpecにおけるFactoryGirlの使い方まとめ - Qiita
http://blog.inouetakuya.info/entry/2013/11/10/201040
