「リーダブルなテストコードについて考えよう ～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://
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
Tama Ruby会議01のキーノートとして発表したスライドです。 https://tama-rb.github.io/tamarubykaigi01/ 参加レポートはこちら。 https://blog.jnito.com/entry/2019/07/07/102734
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
最近のRails関係の仕事内容
RubyやRailsのアップグレードを主なマイルストーンとしつつ全体的に開発体験を良くしていくというタイプの仕事を請けることが多いのですが、仕事を依頼する側の視点に立ってみると「実際のところ業務に参加するとどういうことが行われるのか？」というのがやはり気になると思います。 実際、最近の打ち合わせでもその手の不安について相談されることがあったので、ここ1ヶ月でそれ系の仕事で出したPull Requestを元に、実際に何をやっていたかの例を挙げてみたいと思います。 開発環境構築手順や説明方法の改善 荒れたRuboCopの改善 .rubocop.ymlからTargetRailsVersionを取り除く DEPRECATION WARNING対応いろいろ 既存のメソッドと名前が被っているスコープを別名に変更 RSpecのpositional-argumentsを置換 activerecord-im
Rails アプリケーションの不安定なテストを撲滅したい 〜system spec のデバッグ方法とテストを不安定にさせる要因〜
Rails アプリケーションの開発において、自分の変更に関係のないテストのせいで CI がコケるとストレスですよね？真っ先に直したくなりますよね？不安定なテストを直すのは大変な労力が要ると思ってませんか？実は、たいていのケースは簡単に再現確認ができるし、不安定になる要因もだいたい決まっているし、ログやスクリーンショットを見れば原因も簡単に特定できるんです！ そんなわけで、日頃不安定なテストを潰している身として知見みたいなものをまとめてみました。 今回利用した環境は次のとおりです。 rails 6.0.0 capybara 3.29.0 selenium-webdriver 3.142.4 rspec-rails 3.8.2 Google Chrome 77.0.3865.75 (headless で使用) ChromeDriver 77.0.3865.40 (f484704e052e0b5
はじめに テストコード一般の考え方 壊れにくいテストを書く 実装した通りに動作することではなく、仕様通りに動作することをテストする テストコードはシンプルにわかりやすく書く 失敗の原因がわかりやすくなるように意識する RSpecの書き方 テストケース名をitの引数で明記する letよりもlet!を使う 通常の変数と同じ方針に基づいてlet!を利用する subjectを使わない 不要なcontextでのネストを避ける matcherを適切に使い分ける factoryのデフォルト値に依存しないテストを書く 参考にしたブログ記事等 付録：RuboCop設定 We are hiring! サムネイル画像 はじめに テストコードを書く習慣も、近年ではかなり一般的なものになってきました。 ドワンゴ教育事業のバックエンドチームでも自発的にテストコードを書く文化は根付いており、実際に計測はしていませんが、
CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを（strategy = truncationで）使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_
さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏：リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。
「アプリケーションが壊れているのに検知できないテストコード」を書かないようにするための、べからず集 - Qiita
はじめに テストコードを書くことは重要です。 テストコードがないアプリケーションよりもテストコードがあるアプリケーションの方が望ましいことは間違いありません。 ですが、テストコードも書き方を間違えると、アプリケーションが壊れているのに正しく検知できないテストを書いてしまう可能性があります。 この記事ではそんな「アプリケーションが壊れているのに正しく検知できないテスト」のコード例を「〜するべからず（〜してはいけない）」の形式で紹介し、その修正方法を説明していきます。 サンプルコードはRSpecで書いてます（でも他の言語でも考え方は同じはず） サンプルコードはRailsアプリケーションをRSpecでテストする場合を想定したものになっていますが、基本的な考え方自体は他の言語やテスティングフレームワークでも適用可能なはずです。 RSpecのイロハについて先に学んでおきたいかたは「使えるRSpec入
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った
Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
Kaigi on Rails ( https://kaigionrails.org )の登壇資料です。
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: History of RSpec – Steven R. Baker 原文公開日: 2021/05/09 著者: Steven R. Baker 日本語タイトルは内容に即したものにしました。 私がTDD（テスト駆動開発）をチームで教え始めたのは2001年のことでした。当時のTDDはまだかなり新しい概念でしたので、テストを自動化したチームもほとんどなく、XP（エクストリームプログラミング）やTDDについて聞いたことがある人も皆無でした。テストを最初に書くことで設計を進めるという概念は当時まったく知られていなかったので、TDDを理解するのに皆とても苦労していました（20年経った今でも、この事実が完全に変わったとは言えません）。 思い返せば、あの当時は厳しい状況でした。最善を尽くしてTDDの概念を説明し、どうにかしてチームの関心を惹こう
CircleCI上のRSpecによるテスト実行時間を25min -> 12minに短縮する技術 - ANDPAD Tech Blog
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
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版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい
【Ruby版】xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - give IT a try
はじめに テストダブル（Test Double）について、わかりやすく解説した技術記事はないかな〜と探していたところ、こちらのブログ記事を見つけました。 goyoki.hatenablog.com とても詳しく解説されていたので、まさに打ってつけだったのですが、ふだん僕はRubyを使っているのでサンプルコードをRubyにしてみたいな〜と思いました。 そこで今回のエントリでは、原著者の id:goyoki さんの許諾をいただいた上で、上記のブログ記事の説明文を維持したまま、サンプルコードだけをRubyに書き直してみました。（goyokiさん、どうもありがとうございます！） ただし、Ruby版のコードにあわせて説明文を改変した箇所もいくつかあります。 それでは以下がRuby版の「xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の
はじめに 僕は折に触れて「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が有効なと
はじめに 読みやすくメンテナンスしやすいRSpecを書けていますか？ RSpecはというかRubyはというか柔軟なので色々な書き方ができてしまいます。 ある程度の規模のテストコードでは、油断するとどこで定義されている let なのかわからないものが登場したり、なぜか作られる（あるいは作られない）謎のレコードでテストが失敗したり、そういった辛い目にあったりするのではないでしょうか。 僕がRSpecを書くときに意識していることをまとめてみました。 これを実践するようになってつらい現象にあうことはずいぶんと減り、ずいぶんと読みやすくなったんじゃないかなと思っています。 ※効果には個人差があります。 Ruby on Railsを使ったアプリケーションのテスト向けですがRuby on Rails以外でも使えると思います。 主に以下の影響を強く受けています。 RSpecとセットで使われることが多いFa
GitLab RunnerをGCPでオートスケールさせて安く運用する - OPTiM TECH BLOG
こんにちは。Optimal Bizのサーバーサイドに関する開発を担当している伊藤です。 皆さんCIは何を利用していますでしょうか？ Optimal BizではGitLab CI/CDを利用しています。 単体テスト・ビルド・デプロイ等CIの用途は多岐にわたりますが、実際にそれらを実行するPCを必要な数だけ常に起動しておくと無駄な料金がかかってしまいます。 そこで、今回はGoogle Cloud Platform(以降、GCP)のプリエンプティブル VM インスタンスをGoogle Kubernetes Engine(以降、GKE)でオートスケールさせることで、CIリソースを格安で確保する事例を紹介します。 利用例 Optimal Bizチームの場合は「RSpecをGitLab CI/CDを使って並列実行する」で紹介した大量の単体テストを約20台のノードで並列実行するために利用しています。 ざ
Rubyでテストがこれほど盛んな理由のひとつはRailsの存在にあると私は信じています。Railsフレームワークはテストをできる限り楽しく書けるようにしてくれます。ほとんどの場合、網羅的なRailsテスティングガイドを参照すれば事足ります（少なくとも最初のうちは）。しかし物事に例外はつきものです。私たちの場合「システムテスト」がそれでした。 テストをページのマークアップから切り離す方法については、「Railsシステムテスト」シリーズの次の記事『System of a test II: Robust Rails browser testing with SitePrism』をご覧ください。 Railsアプリケーションでシステムテストを書いたりメンテしたりするのは、正直「楽しい」からほど遠い作業です。この問題に対処するために用いた私のアプローチは、今を去ること2013年に初めてCucumber
Kaigi on Rails 2021 Day1 14:00-14:30 @YusukeIwaki 「Railsの システムテスト解剖学」の発表資料です
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).
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リーダブルテストコード / #vstat
N予備校開発でのRSpecの書き方指針 - ドワンゴ教育サービス開発者ブログ
RSpecのテストコードを実行時に書き換えて実行速度を改善した話 - STORES Product Blog
過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方
FactoryBot the Right Way
RSpecの作者が振り返る歴史（翻訳）｜TechRacho by BPS株式会社
僕がRSpecでsubjectを使わない理由 - give IT a try
rspecを読みやすくメンテしやすく書くために
Railsでブラウザテストを「正しく」行う方法（翻訳）｜TechRacho by BPS株式会社
Railsの
システムテスト解剖学
モックしないテストも書く話 - STORES Product Blog