⚡ From ~30 minutes to ~2 minutes: how a Rails team achieved ultra-fast CI — without rewriting tests.

Parallel RSpec done right, smart workload balancing, PostgreSQL on tmpfs (RAM), and even reconsidering cloud vs physical hardware.

Inspired by a Kaigi on Rails 2025 talk 🇯🇵

🔗 https://rubystacknews.com/2026/02/18/%e2%9a%a1-from-30-minutes-to-2-speed-running-rails-ci-without-cheating-much/

#Ruby #Rails #CI #RSpec #DevOps #Performance #KaigiOnRails

⚡ From ~30 minutes to ~2 minutes: how a Rails team achieved ultra-fast CI — without rewriting tests.

Parallel RSpec done right, smart workload balancing, PostgreSQL on tmpfs (RAM), and even reconsidering cloud vs physical hardware.

Inspired by a Kaigi on Rails 2025 talk 🇯🇵

🔗 https://rubystacknews.com/2026/02/18/%e2%9a%a1-from-30-minutes-to-2-speed-running-rails-ci-without-cheating-much/

#Ruby #Rails #CI #RSpec #DevOps #Performance #KaigiOnRails

As expected, the ~65% #RSpec test coverage meant that there have been several issues which came up during manual testing, including some very pleasantly head-scratching ones 🧠

TIL in #Ruby #RSpec,

this:

expect(File.exist?(old_file)).to be true

can be shortened to this:

expect(File).to exist(old_file)

expect(File).to exist old_file

Neat!

One downside of setting myself the stretch goal of "adding #RSPec tests for all URL routes" is that there are a LOT of them 😅

(`rails routes` says 303)

This is of course making this task take forever (~15 hours' work to improve test coverage from ~40% to ~65%).

But, more also-importantly, it's ruining my "lines of code deleted" metric, I have added over 2000 lines of specs alone 🙈

I'm liking how the #RSpec tests are shaping up overall though.

I'd be really interested to get some review from someone with more experience; I did find a few examples of "request" specs (which is the main layer I've decided to start with) around, but there seem to be several different taste preferences going on.

So far, having a "context" for each combination of HTTP verb + endpoint is working out reasonably, and then separate blocks to test unauthenticated / unauthorised / success

#RSpec interactive debugging with #Neovim: I tried a lot, I failed a lot.

I got this working for other languages ( #Python and #CSharp) and it was a HUGE help, taking away one of the main things I need to leave my editor for.

But something is blowing up and I'm still relatively new to Neotest, DAP, and the various plumbing between them and the test runners.

Woohoo, found my first bug thanks to extended #RSpec coverage 🥳

No luck getting #Simplecov to show me a list of uncovered methods yet, though 🤔

First order of business is to see if #RSpec or #SimpleCov can tell me which methods (as opposed to lines) are covered – I'd be happy enough for now if each controller and model method is at least executed.

Since last toot yesterday I cracked open a barrel of #Rubocop plugins – this really is the most ergonomic linter I've used 🤩 – and made a lot of headway tidying up the #RSpec tests.

(Specifically of debugging third-party packages causing deprecation warnings, praise be to #Rspec's `--backtrace` option and ` config.active_support.deprecation = :raise`)

If your application has a `--color` flag, be like #Rspec, also support `--colour` as an alias, absolute praxis imo

Part of me regrets not finding a way to test S3 sooner, because file uploads have always been a big source of bugs in Levelfly, and I built up a small version-hell nightmare for myself by not checking any of that until deep into #Rails 6.

But maybe this was an OK plan: by the time I got to it, I had a lot of practice with dealing with gem dependency issues, writing #RSpec, and writing tests that require other services – all of which turned out to be crucial to getting it going.

Getting basic #RSpec coverage for the key endpoints going as soon as I'd upgraded to Rails 5 was a great move; those tests have already caught all kinds of issues with the new versions.