個人開発しているRails製のマイクロブログ「Mewst」の少し独特な実装方針 (バックエンド編) - Qiita
最近個人でコツコツ作っていたMewst (ミュースト) というマイクロブログサービスを公開しました。 マイクロブログ「Mewst (ミュースト)」のベータ版をリリースしました | shimba.co Railsを使って実装していて、ソースコードも公開しています。 個人的な好みにより一般的なRailsアプリとは異なる方針で実装しているところがいくつかあるので、この記事ではそれらについてご紹介したいと思います。 個人開発でやっているものなので好き勝手やっています。 この記事を書き始めたときはバックエンドとフロントエンドどちらの方針も書こうかと思っていましたが、思っていたよりも長くなったため2つに分けることとしました。 フロントエンド編はあとで書くかもしれません。 ルーティング定義には基本的に match だけを使用する github.com/mewstcom/mewst/config/rout
技術広報として2023年度に頑張ったこと / What we did well in FY2023 as a DevRel
Railsプロジェクトで発生するflaky testの傾向と対策｜グロービス・デジタル・プラットフォーム
はじめにはじめまして。この一年ほど学び放題のDevExpチームでバックエンド開発のお手伝いをしてるmasa_iwasakiです。 今回の記事では、学び放題のバックエンドとして使われているRailsアプリケーションで実際に発生していたflaky testの事例を中心に、一般的なRailsアプリケーションで発生しがちなケースをまとめました。 個人的に、flaky testの発生パターンは割と定番化している印象を持っています。たとえば、以下の記事に記載されている内容と本記事の内容は共通するものが多いです。 Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社 しかし、同じ原因で発生したflaky testであっても、コードベースが異なれば発生の仕方は変わりますし、なにより原因の調査にかかる手間は大きく異なります。本記事がflaky testに遭遇し
FindyでEMをしている栁沢（@nipe0324a）です。 今回は、FindyのとあるRailsのCIのテスト実行時間を10分から5分に高速化した話をご紹介します。 「CIのテスト実行時間が遅い...」 「CIの実行時間を短くしたい!!」 と感じている方はぜひご覧くださいませ。 Findyでは2024年2月現在、1人あたり1日4プルリクを平均で作っています。静的解析や自動テストなどを即時に行うCI環境がないとスピード感のある開発ができなくなるため、CIを高速で回しタスクを完了させる必要があります。機能も増え、テストケースも拡充したことでCIの高速化が求められるようになりました。 また、個人的には、CIは遅くても10分、理想は5分以内で終わるのを1つの目安にしています。これぐらいのスピード感でCIが完了すると、「プルリク作ってレビュー依頼する」、「レビューコメントもらって対応する」といった
日本語版「Everyday Rails - RSpecによるRailsテスト入門」が発売10周年を迎えました 🎉 - give IT a try
僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」は2014年2月に発売されました。 blog.jnito.com そう、発売からちょうど10年が経ったのです。 いつの間にか10年！僕も全然気付いていませんでした！！ おかげさまで本書は何度となくアップデートを重ねつつ、RSpecの定番の入門書としてたくさんの人に読んでいただいています。 現時点での読者数はのべ6800人以上です。ご購入してくださったみなさん、本当にどうもありがとうございます！ これまでの歴史 どういう流れで本書が翻訳され、現在に至ったのかを簡単にふりかえってみましょう。 2012年5月 原著「Everyday Rails Testing with RSpec」がLeanpubで発売 2013年10月 僕が原著を読み、その感想をブログに投稿 blog.jnito.co
MysqlRewinder という gem を作った | BLOG - DeNA Engineering
gem の概要 database_rewinder という gem があります。 これを使うとテストケースを実行するたびに DB の中身が初期化されて、しかも超速いというすごい gem です。 弊社でもヘビーユースさせていただいていたのですが、あるプロダクトの自動テストにおいて適切にデータが初期化されないケースがあり、 Flaky test の原因となっていました。 今回ご紹介する mysql_rewinder は、この問題を解決するために database_rewinder の代替を目指して開発した gem です。 使用例 Ruby on Rails / RSpec と組み合わせる場合、以下のように利用します。 RSpec.configure do |config| # MysqlRewinder の初期設定 config.before(:suite) do db_configs = A
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った
Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
Kaigi on Rails 2023 現地参加して "E2E testing on Rails 2023" というお話をしてきた - YusukeIwakiのブログ
幸いに登壇のチャンスがいただけたので、Kaigi on Rails 2023に現地参加してきました。 E2E testing on Rails 2023 by Yusuke Iwaki - Kaigi on Rails 2023 2年前の「システムテスト解剖学」という発表の続編的な位置づけで、RailsのE2Eテストを取り巻く技術の解説に徹する発表でした。 自分の発表のスタイルとして、「◯◯したらいいよ」「△△ライブラリ使うといいよ」系の発表にはしたくないというちょっとしたこだわりがあり、とはいえ今回の発表は手を抜くと「Playwright最高だよ、めっちゃいいよ」になってしまうので、注意深くストーリー展開を練って本番に望みました。 Node.jsベースのテストランナーを話す必然性 Railsで何をしたら幸せになれそうか？の定義 じつはあれもこれもしなくても、1個だけ仕組みを作ればいいんだ
こんにちは。サーバーサイドエンジニアの三村（@t_mimura）です。 主に保険薬局と患者さまを繋ぐ「かかりつけ薬局」化支援アプリ kakariのサーバーサイド開発（Ruby on Rails）を担当しています。 今回はRailsシステムのCI時間をコスト追加なしで半減した話をします。 目次 前提 対象プロジェクト CIの状況 改善結果 改善内容 前提知識: CIのキャッシュ機能 webpack buildのキャッシュを活用 RuboCopのキャッシュを活用 ESLintのキャッシュを活用 Jestのキャッシュを活用 RSpec Jobをテスト特性ごとに分割 CircleCIのリソースクラスと並列数の最適化 採用しなかった・見送った改善候補 HAML-Lint, Fasterer, Brakemanのキャッシュを活用 Stylelintのキャッシュを活用 bootsnapを活用 Jestの
RSpecを実行するとWebdrivers::VersionErrorが発生する場合の対処方法 - Qiita
Webdrivers::VersionError: Unable to find latest point release version for 115.0.5790. You appear to be using a non-production version of Chrome. Please set `Webdrivers::Chromedriver.required_version = <desired driver version>` to a known chromedriver version: https://chromedriver.storage.googleapis.com/index.html # ./spec/system/tasks_spec.rb:24:in `go_to_project' # ./spec/system/tasks_spec.rb:14:
RuboCop RSpecからRuboCop CapybaraとRuboCop factory_botが切り出されたけど結局どうすればいいの？ - ANDPAD Tech Blog
こんにちは、 ydah です。最近はというと、料理への情熱が再燃してきました。一時期は作った料理を全て写真に残していたりとしていたのですが、いつの間にか記録を何も残さなくなっていました。何かしら記録を残すことで、前回よりも味も見た目も良くしようと思えるので、記録を残していくようにしたいと思います。やっていくぞ〜！！ トマトとタコのパスタの近影 はじめに 5/11-13 に長野県松本市 まつもと市民芸術館 で開催された RubyKaigi 2023 の Lightning Talks で、 RuboCop RSpec チーム*1と RuboCop RSpec から、 RuboCop Capybara と RuboCop factory_bot を gem に切り出した話をしました。 rubykaigi.org 当日の発表スライドは以下です。 この記事では RuboCop RSpec を現在使
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
RSpec では context 間の違いを表現するときにのみ let を使う - id:onk のはてなブログ
Test which reminded me why I don't really like RSpec | Arkency Blog (日本語訳：Rails: RSpecが好きでないことを思い出したテスト（翻訳）｜TechRacho by BPS株式会社) を見ての感想。 元のコードのイマイチなところは 4 つあって、 params を before で書き換えている *1 it "will succeed" の文言 it { is_expected.to be_success } と expect(result.success?).to eq(true) が混ざっている let が不思議な順序で連発されていて事前条件を読み解けない すべて、これによって何をテストしているのかが分かりづらくなっているという問題を引き起こす。 params を before で書き換えている let(:pa
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が好きじゃないことを思い出してしまうよ 友人の返事: 好きにレビューしていいから。若手が書いたコ
翻訳する目的 Everyday Rails - RSpecによるRailsテスト入門を読み、モック関連と、FactoryBotについて更に知識をつけたいと思いました。どちらも技術本で学ぶのは難しいので、リポジトリのREADMEを通じて学ぶのが良いと考えました。 Google翻訳やDeepLを用いて全文翻訳を行うと、日本語が不自然で読みにくかったので、今後何度も参照することを考えて、自分で翻訳することにしました。 FactoryBotのREADMEの翻訳は既に存在していたので、RSpec MocksのREADMEを翻訳することにしました。 翻訳時のルール Google翻訳やDeepLは利用しない。 わからない単語を辞書で調べるのはOK。 翻訳してみてどうだったか？ 良い点 英語のドキュメントを読む練習になる。 ドキュメントを細部までしっかり読む経験ができる。わからなくても投げ出さない経験がで
この記事は ANDPAD Advent Calendar 2022 の 7日目の記事です。 qiita.com こんにちは、ydahです。 先日のRubyWorld Conference 2022で燗酒の美味しさに感動していたのですが、ふと気がついたら島根の日本酒がたくさん我が家にいました。 気が付くと何故か我が家にいらっしゃった方々(不思議だ...) そして、また気がつくと枡や徳利、平盃も我が家にいらした(不思議ですね...)のでこれから寒くなるので、燗酒を飲んで温まっていこうと思います。 はじめに 本記事では私が所属しているANDPAD検査チームで取り組んだ以下のことについて紹介いたします。 Request specの改善についてやったこと チームとして改善タスクやリファクタリングを推進するための仕組み作り Request specの改善について 長年、様々な人によって書かれてきていた
上のツイートを見て、どうやるのがいいか考えてみました。 以下がその方法です。 遅いテストに:slowタグを付けます（名前は:slowじゃなくても可）。
Leaner 開発チームの黒曜(@kokuyouwind)です。 AWS Startup Community Conference 2022 に CfP を出したので通ってほしい今日このごろです。 さて、今回は Rubocop 警告の修正で少し手間取った話を書きます。 RSpec/MessageSpies に引っかかったコード あるクラスで「Rails.logger に特定文字列を出力していることを検証したい」というケースがあり、この spec を以下のように書いていました。 # ログを出力するクラス class Hoge def log Rails.logger.info('test message') end end # spec RSpec.describe Hoge do describe 'log' do let(:logger) { instance_double(Active
CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを（strategy = truncationで）使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_
さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏：リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。
はじめに こんにちは。入社して4年目になりました、wai-doi です。 お仕事でRSpecでテストを書いていて、 「引数に特定の値が渡された時だけスタブしたい」 ということがありました。そのときどのように書けばよいか分からなかったので、今回は調べたこととその方法を書きます。 実行環境 Ruby 3.1.2 RSpec 3.11.0 サンプルコード 例えば以下の Shopper#buy_fruits メソッドのテストをしたいとします。単純に配列の ['apple', 'banana', 'orange'] を返します。 class Shopper def buy_fruits(shop) basket = [] basket << shop.sell('apple') basket << shop.sell('banana') basket << shop.sell('orange') b
Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel
はじめに テストコード一般の考え方 壊れにくいテストを書く 実装した通りに動作することではなく、仕様通りに動作することをテストする テストコードはシンプルにわかりやすく書く 失敗の原因がわかりやすくなるように意識する RSpecの書き方 テストケース名をitの引数で明記する letよりもlet!を使う 通常の変数と同じ方針に基づいてlet!を利用する subjectを使わない 不要なcontextでのネストを避ける matcherを適切に使い分ける factoryのデフォルト値に依存しないテストを書く 参考にしたブログ記事等 付録：RuboCop設定 We are hiring! サムネイル画像 はじめに テストコードを書く習慣も、近年ではかなり一般的なものになってきました。 ドワンゴ教育事業のバックエンドチームでも自発的にテストコードを書く文化は根付いており、実際に計測はしていませんが、
表題の通りのことができるgem、CiLoggerが便利ですよという話です。 私達は大量のテストをCI上で実行しています。テスト結果を見れば失敗理由が自明なものもありますが、E2Eテストなどでよく起きる「たまに失敗するテスト」の調査はログやスクリーンショットなど、可能な限りの情報を集めないと根本原因がつかめないことが多いです。 そんなときに、特に考えずRailsデフォルトの設定(config.log_level #=> :debug)のままにしておくと、膨大なログの中から該当するテストに関連する行を探し当てる作業が必要になります。これは事前の準備なしではほぼ不可能です。 事前の準備として簡単に思いつく方法は、テスト前後で「どのテストが開始/終了したか」をログに出力することです。 config.around do |example| Rails.logger.debug("start exam
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
Rails defaults to minitest, but much of the community has adopted RSpec—which is right for you? In this article, William Kennedy compares RSpec and Minitest in a new Rails app. Rails is a framework that comes with nearly everything included, focusing on conventions over configurations. Minitest is one of these conventions. Minitest is small and fast, and it provides many assertions to make tests r
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
RSpecを書く上で意識した方がいいと思うことと少しのTips | Offers Tech Blog
こんにちは！Offersを開発しているバックエンドエンジニアのShunです。 前回「テストは絶対書いた方がいい」という記事を書いたので、今回はテストを書く上で留意していることを書ければと思います。 そもそも、テストは絶対書いた方がいい 単体テスト・結合テスト・UseCase テストを書いておくことで、テストファイルを見るだけで仕様を理解できたりします。 また、複雑なメソッドほどテストを書いておくことで、きちんと想定した出力を保証したメソッドの実装ができます。 さらに、一度書いたテストは追加機能・修正対応・リファクタリングなどを行った際に、影響してるか否かを自動でチェックしてくれます。 これにより、ユーザ様への円滑な価値提供並びにサービス品質を保証する大事な役割を担ってくれるのです。（テスト書いてなかった頃が恐ろしい） しかし、きちんと書けば書くほどテストのコード量が爆増する 書けば増えます
RSpecモックメモ
double完全に偽物のオブジェクトを作る。allowなどで定義されていないメソッドを呼び出すとテストが失敗する。 d = double('object') d.hoge #=> 失敗 d = double('object', hoge: 1, piyo: 2) expect(d.hoge).to eq 1 #=> 成功 d = double('object') allow(d).to receive(:hoge) expect(d.hoge).to eq nil d = double('object') allow(d).to receive_messages(hoge: 1) expect(d.hoge).to eq 1 spyほとんどdoubleと同様だが、allowなどで定義していなくても任意のメソッドを呼び出せる。コードは確認していないが、double(...).as_null_
CircleCI上のRSpecによるテスト実行時間を25min -> 12minに短縮する技術 - ANDPAD Tech Blog
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 皆さん、Webアプリケーションのテストを書いていますか。 モック(mock)を使っていますか。 今回は自動テスト上で、偽物だけではなく（要所で）本物を使おうよという話を書きます。 想定読者としては主にRuby on Railsを開発しているバックエンドエンジニアを想定しています。 モックとは 今回のモックの定義は以下にしておきます。 *1 実際の外部サービスや内部サービスの代わりをする偽のサービスを作成することです。 ref: https://circleci.com/ja/blog/how-to-test-software-part-i-mocking-stubbing-and-contract-testing/ Rubyでは外部サービスとの接合部で、 RSpecの allow(xx).
Rails 7.0に対応した「Everyday Rails - RSpecによるRailsテスト入門」をリリースしました！ - give IT a try
僕が翻訳しているRSpecの入門本「Everyday Rails - RSpecによるRailsテスト入門」をアップデートしました。 すでに本書をお持ちの方はLeanpubから最新版をダウンロード可能です。 leanpub.com このエントリでは今回のアップデートの注目ポイントを5つ紹介していきます。 また記事の最後には期間限定の割引情報も載ってます！ 追記：記事内でお知らせしていた割引キャンペーンは2022年5月8日に終了しました。 【もくじ】 ポイントその1：サンプルアプリやサンプルコードが最新のRailsとRSpecに対応！ ポイントその2：統合テストをフィーチャスペックからシステムスペックに変更！ ポイントその3：ファイルアップロード機能をPaperclipからActive Storageに変更！ ポイントその4：その他、最新バージョンのgemを使うように内容をリニューアル！ ポ
Rails 7.0 + Ruby 3.1でゼロからアプリを作ってみたときにハマったところあれこれ - Qiita
Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった！」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい
個人でも業務でもすごくお世話になっている CircleCI について説明したいと思います。 設定する際の Tips など個人的な観点を元に紹介していきます！ CircleCI の構造をざっくりと理解する CircleCI で設定する .circleci/config.yml ファイルの中身の構造について理解していきます。 config.yml は大きく分けて、 version, orbs, executors, commands, jobs, workflows の6つのキーワードに分かれています。 この6つのキーワードを理解することで CircleCI がよくわからない方もざっくりと理解することができます。 version キーワードを除くその他のキーワードを見てもらうとわかりますが、基本的に ****s になっているので複数指定することができます。 では順番にそれぞれのキーワードについ
TL;DR expect{subject}.to raise_error SystemExit exitをテストする状況はそもそも筋が悪い 前置き こんにちは。私は最近miというRails用のマイグレーションジェネレータを作っています。 github.com Railsのジェネレータは内部でThorというライブラリを使用しています。 このライブラリを使用していく上で、一つ問題が発生しました。 処理を途中で切り上げるためにexitメソッドを使用しないといけない事態に陥ってしまっていました。 問題点 exitはその時点でプロセスを終了するメソッドです。 このメソッドの問題点の一つに、テストがしづらくなると言うことがあります。 例えば、以下のようなメソッドをテストすることを考えます。 def do_something # ... if cond # ... exit 1 end # ... en
Kaigi on Rails 2021 Day1 14:00-14:30 @YusukeIwaki 「Railsの システムテスト解剖学」の発表資料です
Help us understand the problem. What are the problem?
はじめに 僕は折に触れて「RSpecではなるべくsubjectを使わない方がいい」という発言をしています。 Qiitaとか見てるとRSpecのsubjectを愛用している人が多そうな印象なんだけど、僕はほとんど使っていません。「subjectは原則使わない。明らかにメリットがあるときにだけ例外的に使用する」が僕のポリシーです。ほら、RSpecの（元）メンテナさんもそう言ってるし。 https://t.co/Rp5EiIxCVb #Qiita pic.twitter.com/pMlN35ihEG— Junichi Ito (伊藤淳一) (@jnchito) 2019年5月28日 そもそもの話として、RSpecではsubjectは無理に使わない、というのが僕の持論です。なぜなら無理にを使うと、いびつなテストコードができやすいから。基本はsubjectなしで書く。明らかにsubjectが有効なと
皆さんこんにちは！2021 年の新卒エンジニア研修ではフリーランスのRailsエンジニアであるigaigaさんをお招きし2つのワークショップを行いました。1つ目はデータベース（DB）のモデリングについて、2つ目はRailsのテストフレームワークであるRSpecについてです！この記事ではそれぞれのワークショップの様子や学んだことについて参加したメンバーがお伝えして行きたいと思います！ DBモデリングworkshop 実施日：2021/06/23 資料：https://github.com/pepabo/training/blob/master/workshop/db_modeling/db_modeling.md ここからは研修に参加した新卒11期エンジニアのゆうくんとやんまーがお送りします。 研修内容 研修は4時間のうち前半に座学を受け、後半に学んだ内容を実践する形で進みました。 前半はデ
まえおき Railsでsystem specを導入するぞ！ というときに、Google検索をすると こういう記事が引っかかるかと思います。 単に「Cuprite使えばいいよ！」ではなく、そもそものシステムテストの必要性や開発経緯なども親切に書かれており、非常に素晴らしい記事です。 ただ、結果的にCupriteを称賛した内容で終わっており、人によっては「Seleniumなんか使わずにCuprite使えばいいんだ！」って思う人もいるかも知れません。 個人的にPlaywrightベースのCapybaraドライバを開発していて、その開発の際にCapybaraのソースとかCupriteの動作とか結構見たので、知見の共有をしておこうかなと思います。 SeleniumベースのCapybaraドライバ がスタンダード。それでも、Yet Another Capybaraドライバを求める理由はなんだっけ？ そ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
私のRSpecの書き方 / How I write RSpec
RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog
お財布に優しいCI改善小ネタ集 - メドピア開発者ブログ
GitHub - asonas/rspec-daemon
RSpec MocksのREADMEを翻訳 - Qiita
RSpec の Request spec をチームで改善していった話 - ANDPAD Tech Blog
RSpecで遅いテストをふだんskipして、たまに全部実行する方法 - Qiita
Rubocop の RSpec/MessageSpies に対応する際は処理順の書き換えが必要
RSpecのテストコードを実行時に書き換えて実行速度を改善した話 - STORES Product Blog
過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方
RSpecで引数に特定の値が渡された時だけスタブしたい - ESM アジャイル事業部 開発者ブログ
RSpec: Behaviour Driven Development for Ruby
N予備校開発でのRSpecの書き方指針 - ドワンゴ教育サービス開発者ブログ
失敗したテストのログだけを出力するぞ - おもしろwebサービス開発日記
Minitest vs. RSpec in Rails
リーダブルテストコード / #vstat
モックしないテストも書く話 - STORES Product Blog
3年の運用で編み出した CircleCI 超設計大全 - Qiita
RSpecでexitを含むコードをテストする - pockestrap
Railsの
システムテスト解剖学
RSpecでNaNを判定する - Qiita
僕がRSpecでsubjectを使わない理由 - give IT a try
DBモデリングとRSpecのワークショップを行いました - Pepabo Tech Portal
2021年6月現在、Cupriteで"正しい"システムテストはできるのか？