CircleCI上のRSpecによるテスト実行時間を25min -> 12minに短縮する技術 - ANDPAD Tech Blog
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
rspecを読みやすくメンテしやすく書くために
はじめに 読みやすくメンテナンスしやすいRSpecを書けていますか？ RSpecはというかRubyはというか柔軟なので色々な書き方ができてしまいます。 ある程度の規模のテストコードでは、油断するとどこで定義されている let なのかわからないものが登場したり、なぜか作られる（あるいは作られない）謎のレコードでテストが失敗したり、そういった辛い目にあったりするのではないでしょうか。 僕がRSpecを書くときに意識していることをまとめてみました。 これを実践するようになってつらい現象にあうことはずいぶんと減り、ずいぶんと読みやすくなったんじゃないかなと思っています。 ※効果には個人差があります。 Ruby on Railsを使ったアプリケーションのテスト向けですがRuby on Rails以外でも使えると思います。 主に以下の影響を強く受けています。 RSpecとセットで使われることが多いFa
rspec-givenですっきりしたspecを書く - Qiita
社内のプロダクトで一部rspec-givenを使い始めたので、ざっと説明を書いておこうかなと。 追記 もう少し細かく、評価タイミングやこう使ったらいいのではないかという方法をまとめました ワンライナーなspecを書きやすくするrspec-givenをもっといい感じに使う rspec-givenとは Given/When/Then keywords for RSpec Specifications とrspec-givenのページに書かれている通り、Given, When, Then などを使ってCucumberライクにspecを書けるextensionです。 rspec-givenを使う理由 すっきりきれいに書ける(と思う)からです。 なんかsubject, let, itはなんかピンと来ない部分がありますが、Given, When, Thenと並ぶと分かりやすいです。 Given, Wh
Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 元記事: Five ways to write a flaky test 原文公開日: 2016/10/21 著者: Kir Shatrov（@kirshatrov） 2017/05/08: 初版公開 2023/03/01: 更新 不安定なテストは、日々の苦労を台無しにしてくれる技術上の負債の一部となります。テストが不安定だとCIが赤信号になってしまい、それだけのために新しいコードのリリースを中断してビルドをやりなおすはめになります。実際のコードはどこもおかしくないのに、どこかがおかしいのではないかという疑念が湧くと、ストレスの元になります。 数百人の開発者と5万件のテスト項目があるような大規模案件1では、不安定なテストが混入する可能性がさらに高まります。 本記事で扱うデモの中には、テストの実行順序に関連するものもありますが、そうでないものも
rspecのdescribe, context, subject, letなどの書き分け - kei-p3’s blog
Everyday Railsを読んでみて、rspecの利便さに改めて気付かされました。 特にAPI周りの実装をすることの多かった自分としては、capybaraによるfeatureテストなんかはこんなことがこんなに簡単にできるのかと驚きました。 しかし、自分としては知りたかった、describeやcontext、letの書き分けといった細かな部分についてはあまり深く触れていなかったので、 自分のいままでの経験上で「こんな感じでやってます」というのを、まとめついでに紹介したいと思います。 テスト名の宣言 - describe, context, it describeとcontextについては、どちらも同じ挙動をするので、テストとしてはどっちで書いても機能するのですが、 言葉の意味合いから下記のように使い分けています。 itについては、エラーがでたときに内容を理解できればいいかなということで、
RSpec 3.6 がリリースされました！
Sam Phippen, Myron Marston, Jon Rowe, Yuji NakayamaMay 4, 2017RSpec 3.6 がリリースされました！ 私たちは semantic versioning への準拠を約束しているので、 既に RSpec 3 をお使いの場合、このバージョンへのアップグレードは簡単なはずです。 しかし、もしバグを見つけた場合は教えてください。 できるだけ早く修正をし、パッチ版をリリースします。 RSpec は世界中のコントリビュータと共に、コミュニティ主導のプロジェクトであり続けます。 今回のリリースには、 50 人以上のコントリビュータによる 450 以上のコミットと、 120 以上の pull request が含まれています！ このリリースに向けて力になってくれたみなさん、ありがとう！ 主な変更 Core: Example の外で発生したエラ
RSpecを並列実行するgemを作っている話 - Qiita
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
RSpecの入門とその一歩先へ ～RSpec 3バージョン～ - Qiita
はじめに 有名な初心者向けのRSpec入門記事として、和田卓人さん(@t_wada)の「RSpec の入門とその一歩先へ」という記事があります。 僕もRSpecを全く知らなかった頃に参考にさせてもらいました。 今読んでもとても素晴らしい資料なのですが、RSpecのバージョンが古く、現状の書き方とマッチしなくなってきているのが少しもったいないところです。 そこで、この記事では和田さんの記事をRSpec 3バージョンに書き直してみようと思います。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション(本記事) 第2イテレーション 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter1 本記事のライセンスについて 本記事は クリエイティブ・コモンズ 表
GitHub - rspec/rspec-rails: RSpec for Rails 6+
rspec-rails rspec-rails brings the RSpec testing framework to Ruby on Rails as a drop-in alternative to its default testing framework, Minitest. In RSpec, tests are not just scripts that verify your application code. They’re also specifications (or specs, for short): detailed explanations of how the application is supposed to behave, expressed in plain English. According to RSpec Rails new version
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01