Are you a Ruby developer? You use Neovim? Then this article is for you. Although the Neovim component is not a hard requirement.
A while ago (almost two years), tired of switching between Kitty windows and inspired by Tj's excellent tutorial on how easy it can be to add custom features to Neovim, I wrote a teeny tiny plugin to run RSpec tests from within Neovim.
It was so much fun figuring out the weirdness of the Lua language that I just loved it. If I didn't know Ruby, I'd agree to program in Lua for full time. And the Neovim aspect only added satisfaction. I felt how the buffers, text lines and words come to life, gain character and preferences after every API discovery.
Spending years in programming I worked on different kinds of projects, tackled fresh ideas, wrote automation scripts for bizarre use cases, but this project was different. I spent so much time in IDEs that file tabs were just openings, means of entry, nothing that I could relate to. And the source code... I have long ceased to see it as “plain” text. Parameters, variables, methods, conditions and expressions, loops and statements, it's all conceptual, intangible.
Now my script runs underneath that text and the result reflects on top of it, treating lines and words as individual entities. The same kind of text developed in one window does something to a text in another. It was unusual, strange and exciting.
Unsurprisingly, this plugin was even more fun to use.
You hit a couple of keys, and watch the thing to test your test assumptions. Sometimes your fingers are still on the keyboard, you still think if that's enough of a test to validate your application code, when the result comes back. A nice green success message on top right corner of your screen or a little "Failure" label at the end of the line where something requires your attention.
Soon it was hard to tell what I enjoyed most was writing tests or running them. I've made myself a small toy.
I was happily playing with it for months. Then there was a no-ruby-coding period. And when I came back again, that fast feedback loop didn't seem that fast anymore. Even simplest test examples took 2 to 3 seconds to complete. While RSpec reported tests duration of around 0.3 seconds, the actual command didn't fall below 2.5.
"Files took 1.76 seconds to load". This refers to the loading of the Rails framework and the application code involved.
The application I'm using here includes the Spring gem. Opening the Rails console, for example, uses the application running in the background, which is what Spring does. It is fast. A lot less than 2 seconds, at least. But the bundle exec rspec command that my plugin used has no idea about Spring.
How I didn't notice this back then is a good question. But from the other hand, 2-3 seconds is not that much. I used to run tests during active development that took minutes. Definitely can wait 2 seconds. Or so I thought, until it started to irritate me.
It turns out Spring has no native support for the rspec command. And yet, as is usually the case, there is this gem: spring-commands-rspec.
So I installed it, generated the bin/rspec binstub. Here is the effect.
Total runtime of 2.8 seconds vs 0.9, almost 3 times faster. Impressive!
Of course, this doesn't mean that Spring will make the whole test suite 3 times faster. The 1-2 seconds difference in loading files disappears within minutes of running the entire test suite. But in the case of running single test examples or individual files over and over during development, it actually can be 2 to 3 times faster.
I updated my plugin to be a wee bit smarter about selecting which command to run RSpec as, and back to happy mode again.
In the end, here are a couple of facts about the spring-commands-rspec gem.
It's minuscule. So small it's hard to call it a gem.
1 class with 4 methods with a total of 5 lines of executable code and 2 more lines integrating with Spring. That's it. That's the whole gem.
But wait. There is more. This code was last updated ten years ago.
Isn't that fascinating? When was the last time you loaded a ten year old library and it still worked?
What a great example of the benefits of robust interfaces. Well done Spring!
Top comments (0)