RSpec: スタブのメソッドの引数にリテラル以外を渡すときは素直に be_an_instance_of を使ったほうがいい｜TechRacho by BPS株式会社
2023.03.09 RSpec: スタブのメソッドの引数にリテラル以外を渡すときは素直に be_an_instance_of を使ったほうがいい オブジェクトの同一性にこだわらなければ、スタブのメソッドの引数には be_an_instance_of を使ったほうがいい 特にgemが返すオブジェクトとの同一性比較は無理にやらないほうがいい 実例 Herという、RESTful APIで得たリソースをRubyオブジェクトにマッピングするgemがあります。 これを使って外部APIを叩きます。 その結果としてHerがパースできないbodyが返ってきた場合、特定のSlackチャンネルに通知するという rescue_from の処理を書きます。 class ApplicationController < ActionController::Base rescue_from Her::Errors::P
Rails: RSpecが好きでないことを思い出したテスト（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Test which reminded me why I don't really like RSpec | Arkency Blog 原文公開日: 2022/11/03 原著者: Szymon Fiedler サイト: Arkency Blog 2023/02/13: 初版公開 2023/02/14: 原文修正を反映（関連ツイート） 最近、別のソフトウェア会社にいる友人がmutantのセットアップについて助けを求めてきました。問題点を発見するためにサンプルテストを共有しながら作業を進めました。Slackチャンネルで以下のスニペットを目にした瞬間、その場で以下のレスを書き込みました。 私: このexampleを見てると自分がRSpecが好きじゃないことを思い出してしまうよ 友人の返事: 好きにレビューしていいから。若手が書いたコ
RSpecの作者が振り返る歴史（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: History of RSpec – Steven R. Baker 原文公開日: 2021/05/09 著者: Steven R. Baker 日本語タイトルは内容に即したものにしました。 私がTDD（テスト駆動開発）をチームで教え始めたのは2001年のことでした。当時のTDDはまだかなり新しい概念でしたので、テストを自動化したチームもほとんどなく、XP（エクストリームプログラミング）やTDDについて聞いたことがある人も皆無でした。テストを最初に書くことで設計を進めるという概念は当時まったく知られていなかったので、TDDを理解するのに皆とても苦労していました（20年経った今でも、この事実が完全に変わったとは言えません）。 思い返せば、あの当時は厳しい状況でした。最善を尽くしてTDDの概念を説明し、どうにかしてチームの関心を惹こう
テストの抽象化を増やしすぎてはいけない理由（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Why avoid too many abstractions in tests? - Write it simple 原文公開日: 2021-02-13 著者: Juan Manuel Ramallo はじめに コードには「プロダクションコード」と「テストコード」があります。プロダクションコードとは、コードベースのうち本番環境で実行される部分を指し、同様にテストコードはテスト環境でのみ実行されるコードベースの部分を指します。プロダクションコードの予行演習はテストコードを介して行われます。 テストコードは「明快で」「読みやすく」「何が行われているのか理解しやすい」ものでなければなりません。shared exampleのようなテストの抽象化は、必ずしもテストコードで不可欠ではありません。 テストコードをDRYにしない理由 プロダクシ
週刊Railsウォッチ（20190806-2/2後編）RSpec CopのLeakyConstantDeclaration、serveoでゼロコンフィグ公開、RuboCopのPerformance/RegexpMatch改修ほか｜TechRacho by BPS株式会社
2019.08.06 週刊Railsウォッチ（20190806-2/2後編）RSpec CopのLeakyConstantDeclaration、serveoでゼロコンフィグ公開、RuboCopのPerformance/RegexpMatch改修ほか こんにちは、hachi8833です。来週の週刊Railsウォッチはお盆休みのためお休みをいただきます🙇。先祖の供養を忘れずに。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください 今回は「公開つっつき会」第13回を元にしています。ご参加いただいた皆さま、ありがとうございます！ ⚓Ruby ⚓awesome-ru
Rails: Timecopを使わなくても時間を止められた話｜TechRacho by BPS株式会社
テストで時間を止めたい時、Timecopを使わないと止められないと思っていましたが、Rails4.1以降は標準のActiveSupport::Testing::TimeHelpersでも止められると最近知りました。 1. Timecopを使った場合 1ヶ月前の時刻で固定する。 Timecop.freeze(Time.current.prev_month) 2. ActiveSupport::Testing::TimeHelpersを使った場合 API: ActiveSupport::Testing::TimeHelpers 1ヶ月前の時刻で固定する。 travel_to(Time.current.prev_month) 元の時刻に戻す travel_back 現在時刻で固定する freeze_time 関連記事 PostgreSQLの現在時刻をフェイクする方法とRailsサンプルコード（翻
RSpecえかきうた｜TechRacho by BPS株式会社
初めまして、takanekoと申します。 入社して以来２年くらい「ブログ書きます！」と言いつつすっぽかし続けたダメWebエンジニアです。 RSpecえかきうた? 「ぼくのあーるすぺっくのかきじゅん」（僕のRSpecの書き順）です。 RSpecの書き方わからない、という方のために、0から書き上げる際の参考になればと思い書きました。 Specを書き始めましょう RSpecにはModel Spec、Feature Spec、Request Spec、System Specなど色々種類がありますが、今回はRequest Specを書いていきます。APIとかのテストをする際に使うSpecです。 書き順がメイントピックなので、細かい実装の妥当性とかは無視して、以下のような簡単な仕様のユーザ登録APIでSpecを書きたいと思います。 API仕様 URL POST /users(format: :json
RSpec: コンポジションできる`be_json`マッチャー（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Embracing composability: be_json RSpec matcher 原文公開日: 2018/03/02 著者: zverok -- 名サイト「rubyreferences.github.io」の作者でもあります。 リポジトリ: zverok/saharspec RSpec: コンポジションできるbe_jsonマッチャー（翻訳） HTTP APIをRSpecでテストするのは、簡単なようでときにはトリッキーになることがあります。レスポンスのJSONをRubyらしい正しいやり方でテストするにはどうすればよいでしょうか？おそらく誰もが最初は以下のように書くでしょう。 let(:response) { call_my_api } subject { JSON.parse(response.body) } it {
やさしいRubyメタプログラミング: RSpecを自分で作って学ぶ（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Build your own RSpec - a gentle introduction to metaprogramming in Ruby 原文公開日: 2018/03/01 著者: Paweł Dąbrowsk 以下の記事を参考に、テスト対象コードとテスト用コードを1つのファイルにまとめて記述しておくと試しやすいでしょう。 Rails tips: コードとテストを同じファイルに書けるRSpec autorun（翻訳） RubyのDSLとメタプログラミングのやさしい入門記事です。 DSL（Domain Specific Language）: 言語を新たに作ることで特定の問題を記述する、プログラミング技法の一種です。Ruby on Railsフレームワークのルーティングや、RSpecの構文はDSLのよい例です。 メタプログラミン
RSpecのexampleや失敗時のメッセージをわかりやすくするコツ（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Cleaner RSpec examples and failure messages 原文公開日: 2015/12/25 著者: Jeroen Weeink サイト: Crafting Ruby RSpecは、テストを書くための多方面に渡る柔軟なDSLを提供します。しかしマッチャーが実に多岐に渡っているため、Minitestのようなテストフレームワークに比べるとマッチャーを正しく使うために頑張りが必要になります。 次のspecをご覧ください。 RSpec.describe ShoppingCart, type: :model do let(:shopping_cart) { subject } describe '#to_order' do let(:product1) { create(:product, price: 10)
Ruby: 私たち、もしかしてat_exit?を使いすぎ？（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Are we abusing at_exit? | Arkency Blog 原文公開日: 2013/06/22 著者: Robert Pankowecki サイト: Arkency Blog Rubyに興味津々の方なら、Kernel#at_exitというメソッドがあることぐらいとっくにご存知でしょう。もしかすると、このメソッドの存在を知らないまま毎日使っているかもしれませんね。このメソッドはさまざまなgemで多くの問題を解決するのに用いられています。むしろ多すぎるぐらいかもしれません。 初級 at_exitの基本を少々おさらいしておきましょう。ご存じの方はこのセクションをとっとと飛ばしていただいて構いません。 訳注: at_exitはIRBやpryだと書いた瞬間に動いてしまうため、ファイルから実行する必要があります。 puts
Rails tips: RSpecテストの高速化/リファクタリングに役立つ4つの手法（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Speed up and refactor your RSpec tests in 4 simple steps 原文公開日: 2018/03/25 著者: Paweł Dąbrowsk どんなアプリであってもテストは非常に重要な部分ですし、テストをきれいに書くこともやはり重要です。しかしテストスイートを高速かつきれいに保つのが困難になることがあります。特に自分より前に（あるいは現在）複数の開発者が寄ってたかって作った案件でそうなりがちです。本記事では、主に2つの面でテストを改善することに注力します。テストで繰り返し出現している共通部分のリファクタリングと、データベースリクエスト削減によるテストの高速化です。準備はよろしいでしょうか？ 1. shared_examples 次の例で考えてみましょう。 class AgePolicy
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 tips: RSpecのスタブとモックの違い（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Ruby on Rails / RSpec - difference between stubs and mocks 原文公開日: 2018/01/25 著者: Paweł Dąbrowsk 本記事を読む前にスタブやモックの使い方も調べておきましょう。 構文の違い 唯一の違いは先頭のメソッドです。スタブではallowが先行し、モックではexpectが先行するでしょう。 利用法の違い スタブは、他のメソッドが実行されないようにして欲しい値を返させるものです。モックは、指定のメソッドが実行されたかどうかを、引数や頻度を指定してチェックするものです。 コード例 例から学ぶのが一番ですので、ひとつコード例をご覧ください。クラスとそれに対応するテストを作ります。 class Message def initialize(user: user
Rails tips: ストーリーのあるRSpecテストを書く（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: RSpec - tell a meaningful story with your tests 原文公開日: 2018/02/19 著者: Paweł Dąbrowsk これまでにRSpecのspyやスタブについて学んできましたので、今回はもっと意味のあるspecを作ってみましょう。テストというと、「どう動いているか」をテストすると考えているかもしれません。しかしそのテストを集めてドキュメントをビルドするときのことについて考えていますか？別に余分なことをする必要はありませんが、しなければならないのは「ストーリーが見えるテストを書く」ことだけです。その方法についてご説明いたします。 ストーリーの骨格 よいストーリーにはしっかりした構造があり、だからこそ簡単に追うことができます。ストーリーを追うためにあちこち彷徨わなければならないとし
Rails tips: RSpecのテスト設計でよくあるやらかし4種（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: RSpec - 4 common tests design mistakes. Do you make them? 原文公開日: 2018/02/13 著者: Paweł Dąbrowsk 私はテストを書くのがとっても好きなのですが、「ヤバいテストを書くぐらいならテストがない方がまし」な状況もあります。テストがなければ全部手動でテストするしかないという覚悟もできようというものですが、ヤバいテストがあるばかりに、自分自身はもちろん関係者まで「問題なし」と誤認してしまいます。 当てにしてはならないヤバいテストかどうかをどうやって突き止めればよいのでしょうか。テスト作成時にやらかしてしまいがちな過ちをいくつかご紹介しましょう。 シンプルなクラスとヤバいテストを1つずつ書いて分析してみることにします。 module Users class
Rails tips: テストから共通機能を切り出すリファクタリング（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: RSpec - refactor your tests and extract common test functionality 原文公開日: 2018/02/07 著者: Paweł Dąbrowsk テストもコードなので、アプリのクラスと同じ要領でリファクタリングできます。さまざまなテストで同じコード片が必要になることはざらにあるので、同じコードを繰り返し書かずに済むと助かります。 たとえばコントローラのテストではよく次のような感じのコードを書きます。 get :some_action expect(JSON.parse(response.body)).to eq({'key' => 'value'}) レスポンスをJSON形式で返すAPIコントローラがある場合のexpectationは普通こんな感じになることでしょう。ヘル
Rails tips: RSpecの`let`ブロックや`before`ブロックは基本避けるべき（翻訳）｜TechRacho by BPS株式会社
2018.04.11 Rails tips: RSpecの`let`ブロックや`before`ブロックは基本避けるべき（翻訳） 概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: RSpec - you should avoid let and before blocks to use natural flow 原文公開日: 2018/02/06 著者: Paweł Dąbrowsk Rails tips: RSpecのletブロックやbeforeブロックは基本避けるべき（翻訳） RSpecの作者はそれなりの理由があってbeforeやletブロックを考案しましたが、本当に必要でない限りこれらの利用は避ける方が賢明です。理由は以下のとおりです。 テストの本体からletの定義にジャンプ（またはその逆のジャンプ）することで、テストの自然な流れを妨げることになります。 letを使うとテスト
Rails tips: ランダムにコケるRSpecテストの修正に便利なbisect（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Ruby on Rails / RSpec - fix randomly failing tests easily 原文公開日: 2018/02/21 著者: Paweł Dąbrowsk テストを書いていて一番ムカつくことのひとつは、テストが失敗したりしなかったりすることです。えてしてこういうspecは、development環境ではコケないくせにCIでコケたりします。CIがよくわからない方はWikipediaの継続的インテグレーションか、Travis CIやCircle CIといったサービスをチェックしてください。 ランダムに失敗するspecのデバッグには時間がかかります。最初にspecの問題を再現できる実行手順を特定してから、次にその問題を修正します。RSpecは問題の修正そのものについては無力ですが、失敗するシナリオを再現
Rails tips: コードとテストを同じファイルに書けるRSpec autorun（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: RSpec autorun - write test and class code in the same file 原文公開日: 2018/02/23 著者: Paweł Dąbrowsk もう皆さまもアプリではテストを書くべきであることは納得いただいているかと思います。これまでにスパイやスタブやモックなどのさまざまなスタブをご紹介しましたが、今回はもう少し一般的なお題にしたいと思います。 ほとんどの場合、コードとテストはそれぞれ別ファイルに保存するのが自然ですが、たとえば教育現場やデモなどでコードとテストを同じファイルに書く必要が生じることがあります。こんなときにはRSpecのautorun機能が役に立ちます。rspec gemがインストール済みであれば、ファイルを1つ作成してたとえばtest.rbという名前にし、ファイルの冒
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
