The RailsNotes Newsletter 🟥 ISSUE #11

🟥 ISSUE #11 (RSpec, System Specs, Fuubar)

The Kawaii RSpec testing newsletter edition has arrived!

Welcome to The RailsNotes Newsletter — Issue #11!

Let’s celebrate 500 subscribers! 🥳🥳🥳

It’s been a few weeks in the making, but we finally crossed the 500 mark! 🙌Milestones like this always excite me, and I feel like this is where a newsletter starts to feel “big” — 500 people is a lot!

Alongside the newsletter, the blog has also been quietly growing in the background — this week the main RailsNotes blog hit record numbers for search traffic, which was great to see! 📈 It means people are reading my articles and finding them useful, which is awesome.

Terrible screenshot of the Google Search Console page for the RailsNotes blog.

This newsletter is about RSpec and testing! 🏆

Lately, I’ve been diving into the difference between RSpec’s system and feature specs (not as easy a feat as you might imagine!). Over the last few months, I’ve been going deep into testing as a whole, and this is the first article I’ve pulled out.

Like a few others, this article came from building RailsNotes UI, where I spent some time refactoring my feature specs into the “new” system spec standard (I’m not sure if 2017 should be considered “new” anymore…)

I’ve also included a few other handy RSpec articles and tools — let’s go!

FEATURED ARTICLE —

Trying to encapsulate “refactoring RSpec specs” into a cool pic is ~kinda tricky!~, but this one was 1. vaguely on-topic and 2. looked sick, so here you go 😎

You wouldn’t believe how long I spent researching this article! For years now, system specs have been the preferred end-to-end test for RSpec, and yet it’s incredibly difficult to find any good information and articles on them.

I wrote this article to bring all that information together, and walk you through refactoring feature specs into system specs, should you wish to go down that path (don’t worry, it’s not hard). There are some great benefits too!

System specs, being the newer spec type, have a few handy features on top of feature specs — it’s much easier to swap out test drivers and use something like selenium or playwright over rack_test. They also keep the test database clean, so you don’t need to use a gem like database_cleaner.

Worth a read if you use RSpec and are curious!

🌐 MORE ARTICLES —

If you want to learn more about system specs and feature specs, try this. Straight from the fish’s mouth 🐟, this is the official explanation from RSpec.

It’s been really interesting diving into the history behind feature specs and system specs — RSpec implemented end-to-end tests before Rails natively supported them (as feature specs), and then released system specs as a “next-gen” feature spec, which could take advantage of the system test functionality Rails 5.1 shipped with.

I use BetterSpecs as a reference all. the. time! Essentially, it’s a collection of RSpec best practices and tips — some can be a bit contentious, but overall I think they’re handy guiding principles.

As someone still pretty new to RSpec testing, it’s great to have a place to fall back on and reference if I get stuck, or need help designing my tests.

Did you know that RSpec supports custom formatters? Fuubar is one, and it shows you a progress bar [ 2/10 ====> ] as your specs run. This is something I didn’t know I needed, but now love — small, but super handy!

It takes 2 minutes to install and gives you more feedback than the usual RSpec dots and F’s morse code ( …..F….FF…….F). It’s especially helpful when working on a larger group of tests at once!

— ⚒️ HANDY TIP — 

→ Run specs from a single file, from a specific line

You probably know that you can tell RSpec to run a single spec, by running rspec spec/path/to/spec.rb.

But did you know, that you can go a step further and specify a starting point inside a single spec file? This is handy if you have lots of specs in a single file, or are adding a new spec to a file and just want to run it solo.

For example, to run spec.rb from line 43, we could do rspec spec/path/to/spec.rb:43.

RSpec does the work of figuring out how to load your test data, and then runs the subset you specified. For example, if you target a context: block, RSpec will run the whole block.

43| context "with access" do
44|   user.grant_access!
45|
46|   scenario("...") do
47|    ...
48|   end
49| end

# run only specs in context from line 43
> rspec spec/system/user_access_spec.rb:43

Run options: include {:locations=>{"./spec/system/user_access_spec.rb"=>[43}}

Finished in 0.16509 seconds (files took 1.91 seconds to load)
1 example, 0 failures