「リーダブルなテストコードについて考えよう ~VeriServe Test Automation Talk No.3~」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
Rails Developer Meetup 2019での発表資料です!可読性の高いテストコードを書くためのコツについて話しました
はじめに 読みやすくメンテナンスしやすいRSpecを書けていますか? RSpecはというかRubyはというか柔軟なので色々な書き方ができてしまいます。 ある程度の規模のテストコードでは、油断するとどこで定義されている let なのかわからないものが登場したり、なぜか作られる(あるいは作られない)謎のレコードでテストが失敗したり、そういった辛い目にあったりするのではないでしょうか。 僕がRSpecを書くときに意識していることをまとめてみました。 これを実践するようになってつらい現象にあうことはずいぶんと減り、ずいぶんと読みやすくなったんじゃないかなと思っています。 ※効果には個人差があります。 Ruby on Railsを使ったアプリケーションのテスト向けですがRuby on Rails以外でも使えると思います。 主に以下の影響を強く受けています。 RSpecとセットで使われることが多いFa
What is Better Specs Better Specs is a collection of best practices developers learned while testing apps that you can use to improve your coding skills, or simply for inspiration. Better Specs came to life at Lelylan (open source IoT cloud platform) and checking out its test suite may be of inspiration. Better Specs focus on Rails testing, but our goal is to create testing guidelines covering mos
This RSpec style guide outlines the recommended best practices for real-world programmers to write code that can be maintained by other real-world programmers. RuboCop, a static code analyzer (linter) and formatter, has a rubocop-rspec extension, provides a way to enforce the rules outlined in this guide.
背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。 業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。 おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。 こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して
みなさんはこんなふうにRailsアプリケーションを作ったことはありませんか?たとえば、ブラウザをポチポチとクリックするだけでテストを終わらせて「たぶん大丈夫」と思い込んだり、「とにかく全部うまくいきますように」とただ祈るだけだったり……。 心配しないでください。それは誰もが通る道です。アプリケーションのテストやテスト駆動開発はRails開発における重要なトピックですが、巷の参考書を見ると適当な説明で済ませているものも多かったりします。本書「Everyday Rails - RSpecによるRailsテスト入門」では、どのようにして私がそうしたテクニックを身につけたのか、そして、どのようにしてコードの信頼性を上げ、ブラウザ上で延々とテストしなくて済むようにしたきたのかをみなさんに説明します。 対応バージョンについて2024年1月のアップデートで、本書のコンテンツをRails 7.1とRSpe
Test Design RSpec General guidelines Eager loading the application code Ruby warnings Test order Test flakiness Test slowness Don’t request capabilities you don’t need Profiling: see where your test spend its time Installation Generate the JSON report How to interpret the flamegraph Optimize factory usage Let’s talk about let Stubbing methods within factories Stubbing member access level Additiona
RSpec 3.7 has just been released! Given our commitment to semantic versioning, this should be an easy upgrade for anyone already using RSpec 3, but if we did introduce any regressions, please let us know, and we’ll get a patch release out with a fix ASAP. RSpec continues to be a community-driven project with contributors from all over the world. This release includes over 127 commits and 31 merged
The web development world is changing fast. I feel that we are moving towards splitting monolith web applications in two, by extracting backend part into an API. This solution, even though it has many pros, it brings in some difficulties as well. One of which are end to end tests. It may be really tricky to execute those tests in a proper way, especially when we don't have that much of a control o
Stability can become an issue as web applications evolve and grow – integration tests provide a great way to perform end-to-end tests that validate the application is performing as expected. Integration test with RSpec and Capybara When writing integration tests, try to model the test around an actor (user of the system) and the action they are performing. # spec/features/visitor_signs_up_spec.rb
ジョブの実行をテストしたいとき、キューに入ったことをテストしたいだけのときと、その実行結果まで含めてテストしたいとき(つまり同期実行したいとき)がある。 前者であればRails.application.config.active_job.queue_adapter = :testで足りるが、後者を実現するためにはどうすればよいだろう。 方法はいくつかあって、まずはRails.application.config.active_job.queue_adapter = :inlineとする方法。 これは簡単に同期実行は実現できるが、こんどはキューに入ったことが確認できなくなってしまうし、他の非同期のままにしておきたいところまで影響がでてしまう。 またSidekiqを使っているのであればSidekiq::Testing.inline!やSidekiq::Testing.fake! で制御すること
当文書はRails + Rspec + Capybara環境を想定しています。 他のアプリ/テストフレームワークを利用したい場合は公式のREADMEを参照願います。 概要 Capybara = UIテストのためのrubyフレームワーク オープンソース / MITライセンス ページの表示、フォームの入力、ボタンのクリック等のUI操作をテストコード上で実行できる 複数のテストフレームワークから利用できる MiniTest, RSpec, Cucumberなど 複数の ドライバ (テスト環境, ヘッドレスブラウザ)を選択して利用できる Rack::Test, Selenium, Webkitなど 導入 インストール gemをインストールする。 Railsの場合、バージョンによってはデフォルトでGemfileに追加されている。
Want to speed up your test suite? Reduce the number of objects persisted to the database. With Factory Bot, this is really easy; instead of using build or create to instantiate your models with data, use build_stubbed! build_stubbed is the younger, more hip sibling to build; it instantiates and assigns attributes just like build, but that’s where the similarities end. It makes objects look like th
ユーザーエージェントの切り替え PCスマホで処理を切り替えるなど、ユーザーエージェントを参照して処理を行うactionをテストする場合には、次のようにユーザーエージェントを設定することでテストできます。 RSpec.describe HogeController, type: :controller do describe "GET #index" do context 'iPhoneの場合' do it "returns http success" do request.env["HTTP_USER_AGENT"] = 'Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X; en-us) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Small steps to DRYer RSpec 原文公開日: 2017/01/22 著者: Victor Shepelev-- ウクライナ在住のRubyプログラマーで、SciRubyのメンテナーとメンターでもあります。 2017/11/29: 初版公開 2023/07/11: 更新 🔗 これは何? RSpec APIは可能な限りDRYで読みやすいDSLへと絶え間なく進化し続けています。しかし、specをさらにDRYにできる方法(トリックや追加メソッドなど)はまだまだあるのです。 警告: 本記事を読んで「この方法を使うより先に、テストしやすいコードを書けるように設計を見直す方がいいのでは?」と言いたくてたまらなくなるかもしれませんが、そうした方法は既に知られているとお考えください。 更新情報(2017/08/15): sah
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く