Here are my notes:

The importance of a well-crafted pitch

I already wrote about the differences between my story and my history – or how I had crafted a pitch to present my convoluted professional path – but it bears repeating the benefits of a pitch:

• It allows the people you talk to to verify you’re not a complete fluke.
• It hooks your audience and gets out of the way quickly so you can focus on what makes you a great hire / freelancer.
• It filters out the clients/teams with which you’re not compatible: mindset, values, etc.

The pitch came from a place of being tired of faking a competency in software engineering I did not have at the time (circa 2018). So, in a sense, it was a way to own my story and to celebrate what I had learned in the previous 10 years of my professional life.

It’s also a great punchline – from stained-glass master to software engineer sticks in the brain and you become memorable.

The value of transferable skills

My first work in tech – as part of a tech start-up marketing team – was due to my ability to convey complex topics to average people. Namely, I worked with an agricultural professional syndicate to explain the European Common Agricultural Policy through drawings and infographics. This specific experience, quite far from tech, got me through a door which later led to becoming a programmer.

Software engineering is a lot like this:

• You take a complex set of problems that you need to intimately understand.
• You organise and explain them to shareholders / clients.
• You translate these into specifications then into code.

My first piece of writing – tech wise – was about APIs. I wrote it, while being a marketer, mostly because the CTO of my then-employer had started his explanation with these very words:

An API is a contract.

An explanation that had left me more confused than ever.

Throughout all my various careers, I acquired a lot of skills I now transpose to building software.

Writing is learning

Ever since I started learning programming, I have written about my learnings. It’s scary to show the world what you (don’t) know – or a slice of that, to be honest – but it also shows an appreciation for learning and contributing to the community.

Most problems we tackle as software engineers are not that uncommon. So writing about our findings allows other developers to solve the same problems faster.

Using my website as a worry stone is a good way to convey the care I take in my practice. It helps me refine my craft, whether it takes shape as words, page layouts or illustrations. Writing is also a great way for me to properly store what I learn in my brain.

All in all, my writing has opened more doors than it has closed.

Reflecting on my first freelancing gig

In a previous post, I briefly touched on my first experience as a freelancer, some 15 years ago. Jess’ question about this part of my life was a great way to do a bit of a retrospective on it. What changed between then and now is mostly that I became an all-round better human. Sure, I added a few processes to my freelancing practice, but the game changer was simply growing and learning as a person. Less maturity issues.

We should learn to share more publicly the things that are wrong or imperfect. Serving clients is not always about being perfect, but about learning how to do it. Focus on building a good attitude on top of a good skill set, and you’ll love working for yourself. Shift the focus from the end goal to the daily practice.

We talked about so much more: finding support as a freelancer, decoupling value from time billed, trying to build a first small-scale product just for fun, etc.

Thank you so much to Jeremy and Jess for having me on the pod. It was a blast!

Cheers,

Rémi - @remi@ruby.social

While preparing my upcoming talk – Lost in Minitest, the missing guide for Minitest tourists – I dug into how Ruby on Rails pulls in Minitest. And there I found the answers to my burning question: why on Earth does the following test fail?

require "test_helper"

class CustomerIdentificationTest < ActionDispatch::IntegrationTest
  before { @customer = customers.buffy }
  
  it "checks proofs of identification" do
    get customer_identification_path(@customer)
    
    assert_response :success
  end
  
  describe "when the customer has already been verified" do
    setup { @customer.update(verified_at: 2.days.ago) }
    
    it "returns a :success response" do
      get customer_identification_path(@customer)
    
      assert_response :success
    end
  end

These tests look pretty unremarkable:

• The main context checks the response status for a new customer.
• The nested context checks the response for an existing customer.

A few things worth noting:

• I’m using the Minitest::Spec syntax.
• We’re in a Ruby on Rails app (see the < ActionDispatch::IntegrationTest).
• Several people are working on the test files.

Wait, what? How did I infer this?

Notice the difference in how each test is set up? The first test uses the before block syntax that is part of Minitest::Spec. The second test uses the setup block syntax, which is the Rails custom syntax. Minitest being pretty lax about conventions, two people used different syntaxes in the same file.

Is it problematic, though?

  $ bin/rails test
  Running via Spring preloader in process 31584
  Run options: --seed 16480
  
  # Running:
  
  .......................E
  
  Error:
  CustomerIdentificationTest::when the customer has already been verified#test_0001_returns a :success response:
  NoMethodError: undefined method 'update' for nil test/integration/customer_identification_test.rb:6:in 'block (2 levels) in <class:CustomerIdentificationTest>'

Well, looks like it is.

A detour on picking a standard

I’m big on picking a standard and moving on. But I also know that sometimes, you have to give yourself time to play with things before committing to a guideline.

It’s like living in a house: live in it for a while before you start knocking walls down.

Due to the lack of Minitest onboarding, we were careful not to draw rules early on. We wanted to feel where our setup was stretching at the seams. What was working for us and what was not.

Coding with feelings? Why not.

Back to our failing test

Taking the time to feel our way through our setup allowed us to experiment with our tests. Here’s an updated version of the failing test, where I inverted the setup and before blocks.

require "test_helper"

class CustomerIdentificationTest < ActionDispatch::IntegrationTest
  setup { @customer = customers.buffy }
  
  it "checks proofs of identification" do
    get customer_identification_path(@customer)
    
    assert_response :success
  end
  
  describe "when the customer has already been verified" do
    before { @customer.update(verified_at: 2.days.ago) }
    
    it "returns a :success response" do
      get customer_identification_path(@customer)
    
      assert_response :success
    end
  end

Can you see where this is going?

  $ bin/rails test
  Running via Spring preloader in process 57332
  Run options: --seed 23226
  
  # Running:
  
  ...............................................................................................................................................
  
  Fabulous run in 2.511829s, 56.9306 runs/s, 199.8544 assertions/s.
  143 runs, 502 assertions, 0 failures, 0 errors, 0 skips

Yep, using setup first then before works. Flip them and it blows up. Let me tell you, this one had me scratch my head for a while.

Okay, why does it fail, then?

Because of how Rails integrates Minitest, specifically in how it resolves the lifecycle hooks of the tests.

A dive into Minitest hooks lifecycle

When Minitest executes your code, it runs some hooks around your test setup and your tests’ examples. Those hooks are:

• empty methods by default
• meant for library and framework extensions
• not meant to be used in tests’ setup

You can check the Minitest code.

One more thing: the Minitest::Spec before block is just syntactic sugar for Minitest::Test#setup. So both def setup and before block are equivalent.

┌─────────────────────────────────────────┐
│         TEST EXECUTION STARTS           │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│      1. before_setup (hook)             │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│      2. setup (method)                  │
│      - def setup or before block        |
│        are executed here                |
│      - Runs once before each test       │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│      3. after_setup (hook)              │
└─────────────────────────────────────────┘
                    ↓
┌═════════════════════════════════════════┐
║      ★★★ MY TESTS RUN HERE ★★★          ║
└═════════════════════════════════════════┘

Whether I use the vanilla def setup or the Minitest::Spec before block, Minitest treats them the same. They will both run after the before_setup hook.

Ruby on Rails, though, makes things muddy.

Ruby on Rails has entered the chat

In this instance, Rails does two things that will impact my tests:

• Exposes a setup block to use in lieu of the def setup.
• Hooks into Minitest by prepending its own setup strategy to ActiveSupport::TestCase.

In its setup strategy, it hooks the setup block into before_setup.

  # activesupport/lib/active_support/test_case.rb
  
  module ActiveSupport
    class TestCase < ::Minitest::Test
      Assertion = Minitest::Assertion
      
      class << self
        prepend ActiveSupport::Testing::SetupAndTeardown
      end
    end
  end
  
  # activesupport/lib/active_support/testing/setup_and_teardown.rb
  
  module ActiveSupport
    module Testing
      module SetupAndTeardown
        module ClassMethods
          # Add a callback, which runs before <tt>TestCase#setup</tt>.
          def setup(*args, &block)
            set_callback(:setup, :before, *args, &block)
          end
        end
      end
    end
  end

What it means for us:

• We now have three ways of building a setup for our tests: def setup (vanilla Minitest), setup block (Rails’ Minitest), before block (Minitest::Spec)
• Each looks pretty similar to the next.
• Mixing and matching will work most of the time…
• BUT (!) these blocks are not executed at the same time due to the way Rails plugs its setup block in the Minitest lifecycle. So based on the order of declaration, some of my tests will fail!

┌─────────────────────────────────────────┐
│         TEST EXECUTION STARTS           │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│      1. before_setup (hook)             |
|    ⚠️ Rails plugs its setup block here  |
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│      2. setup (method)                  │
│      - def setup or before block        |
│        are executed here                |
│      - Runs once before each test       │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│      3. after_setup (hook)              │
└─────────────────────────────────────────┘
                    ↓
┌═════════════════════════════════════════┐
║      ★★★ MY TESTS RUN HERE ★★★          ║
└═════════════════════════════════════════┘

So when I mix the setup block and the before block syntaxes in a test file, they are not executed in the order I think they are.

No matter how deep the setup block is nested in my test file, in Rails, it’ll always be executed first in the before_setup hook.

So the fix to my initial problem is simple: in a Rails app when using Minitest::Spec, don’t mix setup and before blocks.

Closing thoughts

Funny how such a simple mistake – mixing setup blocks and before blocks – will have you neck-deep in parts of two codebases to understand what’s what.

Of course, this post begs the question: why Rails did not handle the Minitest::Spec syntax too?

I don’t have a definitive answer, but my guesses are:

• Harder to inject the before block in the before_setup without hijacking Minitest (and making the connection brittle)?
• Because Rails is bullish on the vanilla Minitest syntax and did not want to port the Spec syntax?

If you were one of the contributors who worked on this part of Rails, I’d love to know!

You might have noticed several things in my initial test:

• Why not use let instead of before | setup? I used contrived examples for clarity. Usually, I’d use let for instantiating data and before for additional setup like authentification, stubbing, etc…
• Despite using Minitest::Spec, my test class still uses the Rails-styled inheritance – class CustomerIdentificationTest < ActionDispatch::IntegrationTest – instead of the describe CustomerIdentification do syntax one could expect. This is because Minitest::Spec is not set up properly. But this will be a story for another post.

Well, that was quite the rabbit hole! I now know the why behind some of the gotchas I’d written previously.

Anyway, I hope you enjoyed this one as much as I enjoyed writing it.

Cheers,

Rémi - @remi@ruby.social

I had already been a freelancer twelve years ago, and it did not go well. I was working too much, for too little, and some clients never paid me for my work. I was young(er) but I learned my lesson: freelancing is a whole extra job, on top of your core offering.

So when the opportunity arose last year, I knew I needed to get better at being a “company”.

A year of freelancing

I started freelancing at the very end of 2024. After a taxing four-month job search – that only emphasized how broken some tech companies are – I decided to switch my approach.

I reached out to Sunny – an internet pal I’ve known for years – and asked him if he needed an extra pair of hands to ship more features for his company Cults. And he said “yes”.

A week later, Yves – a Le Wagon alumnus – asked me if I was available to help his team tackle their more complex tasks and get some of their velocity back. And I said “yes”.

Both clients needed half of my time. So I was able to fill my week almost instantly.

Working with both Sunny and Yves has been an absolute joy. Some cool projects I built for them even inspired some recent posts on this blog.

Professional wins

My professional goal for 2025 was to survive the year. Between layoffs, AI coming for our jobs, and the overall LinkedIn-ish narrative, it felt as if I was doomed to switch careers (again).

And yet, in case you didn’t notice already, 2025 was a good year for me work-wise:

• Two happy clients with whom I built (and keep building) a relationship based on trust, values and value. You can’t get better than that.
• A lot of projects shipped and billed which leaves me with a full year of runway.
• A solid progression both technically and product-wise:
  • I’ve kept digging into Ruby and Rails internals.
  • I discovered new patterns and products.
  • I worked hard to make sense of Typesense (pun intended).
  • I’ve started building some foundational knowledge back on the front-end side of things (HTML, CSS, JS and the whole Hotwire).
  • And of course, Minitest. A lot of Minitest.
• A lot of impactful features were shipped with little to no disruption for users. Some were critical and done on a tight schedule.
• Working with two teams allowed me to create bridges, and to apply what I had learned within one codebase to the other.
• I worked on my tooling and processes, which allowed me to deliver faster and better.
• In early 2025, I joined a local cooperative to which I delegate most of my admin. It’s a great way to reclaim ownership of my work environment, and the people there are both great and super helpful. This has proven to be a true multiplier for me.
• From the get-go, I knew I needed to work on how to run my business. I built simple processes for time tracking, invoicing, note-taking, etc. This has allowed me to spend less time on boring tasks and more time on being a true partner for both teams.

An aparte on the job market

Whether you’re looking for a job or a freelance gig, the market has been rough for a few years now. Let’s not even talk about the rest. *gestures wildly at everything that has happened in the world*

But here’s my main takeaway: a lot of the “hot” companies from a few years ago now have ridiculous expectations for candidates, while offering very little in return. This has created an interesting shift: companies that weren’t sexy now attract great people. And great people get to work with smaller teams, cooler products, and often healthier finances.

Personal wins

I don’t like to share personal stuff on the blog. There, I said it! What can I say, I’m a very private person. But I’ll make an exception today.

The five coolest things I did this year:

• Making time for my family: Wednesday afternoons with the kids, lots of time off during school holidays, and a real effort to make the little ones active participants in our family life.
• Keep working on my relationship with my partner of 16 years 🫶.
• Getting my health in a better place: resumed boxing after a 10-year hiatus, finally got treatment for my allergies.
• Working on my friendships: It won’t come as a surprise if I say men usually suck at understanding what makes a friendship and how to nurture one? Well, I worked on that. And I’m happy about it.
• Realized I’m likely ADHD and/or on the spectrum: Not through a formal diagnosis, but by ticking boxes as others got theirs. I also stopped masking, and started learning what actually works for me.

Manifesting for 2026

As I said earlier, my professional goal for 2025 was to survive the year. And I think I’ll keep this as one of my goals for 2026.

But I also want to leverage this good first year to plant some seeds.

Here’s what I’m planning:

• Make my clients happy: This one goes without saying. I’ll keep delivering great features, good communication, and value to the people trusting me with their business.
• Learn HTML and CSS from the ground up: I want to develop a deeper appreciation for these languages (and build more stuff with ‘em)!
• Invest in my freelancing practice: Time, money, work on website, nail my main value proposition, write more, etc.
• Get help: I can’t do everything alone. This year, I’ll invest in getting help. Most notably, I need help building stronger foundations for my business and shaping a new offer.
• Meet people as people: In the age of LLMs and the content rat race, I believe genuine connections will matter more than ever. I plan on going to more Ruby meetups, joining some of the folks at Cults at Rubicon in Rimini in May, and simply getting a lot more genuine human interaction.

If you’ve made it all the way to the end, thank you for reading words written by a human. You rock! (And do you know I have a RSS feed? Just saying.)

Cheers,

Rémi - @remi@ruby.social

let over @ivar

So far, in my setup, I only used ivars to store a User accessible in my test examples:

  class UserTest < Minitest::Spec
    before do
      @user = User.new(first_name: "buffy", last_name: "summers")
    end

    it "returns the capitalized full name" do
      expect(@user.full_name).must_equal "Buffy Summers"
    end
  end

However, Minitest::Spec allows me to use the let(:user) method instead of @user.

If you use RSpec, this will look very familiar. If you don’t, let is a method exposed by the DSL, that allows you to define memoized instance variables accessible in your test examples through accessors.

  class UserTest < Minitest::Spec
    let(:user) { User.new(first_name: "buffy", last_name: "summers") }

    it "returns the capitalized full name" do
      expect(user.full_name).must_equal "Buffy Summers"
    end
  end

No more @user, just a plain user, as Minitest::Spec let adds an accessor to my instance variable.

Also, I no longer need the before do ... end block to define variables. I’ll only use before do ... end if I need a more complex setup:

  class UserTest < Minitest::Spec
    let(:user) { User.new(first_name: "buffy", last_name: "summers") }

    before do
      Account.create(user:, tokens: 100)
    end

    it "returns the capitalized full name" do
      expect(user.full_name).must_equal "Buffy Summers"
    end
  end

before do ... end remains the standard way to create objects not directly used in test examples or to mock objects.

let lazy evaluation

let allows Minitest to lazily evaluate the variable when it’s called in a test example. Repeated references of let within the same test example won’t trigger a re-evaluation. It means Minitest won’t run User.new multiple times within a test example, but beware of mutations.

If I share a let across test examples, the let will be re-evaluated, so I don’t need to worry about mutability. States won’t leak from one it case to the next.

Minitest does not have a let! method (like RSpec does). If you need to create objects required for your tests but not explicitly referenced, use the before do ... end method.

Use subject over explicit calls to the tested method

Minitest::Spec also adds the subject method:

  class UserTest < Minitest::Spec
    subject { user.full_name }

    let(:user) { User.new(first_name: "buffy", last_name: "summers") }

    it "returns the capitalized full name" do
      expect(subject).must_equal "Buffy Summers"
    end
  end

subject replaces explicit calls to the method I test. It’s a syntactic convenience that lets me define the subject of the current scope. I find it easy to read and handy when dealing with nested contexts:

  class UserTest < Minitest::Spec
    describe "#full_name" do
      subject { user.full_name }

      let(:user) { User.new(first_name: "buffy", last_name:) }

      describe "when the user has a one-word last name" do
        let(:last_name) { "summers" }

        it "returns the capitalized full name" do
          expect(subject).must_equal "Buffy Summers"
        end
      end

      describe "when the user has a two-word last name" do
        let(:last_name) { "anne summers" }

        it "does not return the capitalized full name" do
          expect(subject).wont_equal "Buffy Anne Summers"
        end
      end
    end
  end

The output for these tests is:

  lab/minitest-post → ruby user_test.rb --verbose
  Run options: --verbose --seed 4199

  # Running:

  UserTest2::#full_name::when the user has a one-word last name#test_0001_returns the capitalized full name = 0.00 s = .
  UserTest2::#full_name::when the user has a two-word last name#test_0001_does not return the capitalized full name = 0.00 s = .

  Finished in 0.001340s, 1492.5373 runs/s, 1492.5373 assertions/s.
  2 runs, 2 assertions, 0 failures, 0 errors, 0 skips

I like how combining let and subject lets me run multiple contexts while only adjusting the relevant variable. Since lets are lazily evaluated, the initial let(:user) can leverage contextual lets to instantiate a new User with the ad hoc local variables.

In plain Minitest, it’d look like this:

  class UserTest < Minitest::Test
    def setup
      @user = User.new(first_name: "buffy", last_name: "")
    end

    def test_full_name_with_one_word_last_name
      user.last_name = "summers"
      full_name = user.full_name

      assert_equal "Buffy Summers", full_name
    end

    def test_full_name_with_two_word_last_name
      user.last_name = "anne summers"
      full_name = user.full_name

      refute_equal "Buffy Anne Summers", full_name
    end
  end

Since @user = User.new is evaluated immediately during setup, it can’t take advantage from local variables to create different variations of a User on the fly.

Note that there is no named subject (aka subject(:name)) in Minitest.

An aside: I guess this is one of the reasons Minitest maintainers aren’t fond of porting assertions to expectations, because on top of the work, they constantly have to deal with comparison. Which, let’s be honest, is a pain in the back.

Nested describe blocks

My last example shows that we can nest describe blocks!

There are no context in Minitest, but describe blocks are still a nicer way to show context granularity compared to plain Minitest nested classes.

Be careful not to nest describe block too deeply:

  class UserTest < Minitest::Spec
    describe "#full_name" do
      subject { user.full_name }

      describe "when the user has a two-word last name" do
        let(:user) { User.new(first_name: "buffy", last_name:) }
        let(:last_name) { "anne summers" }

        it "does not return the capitalized full name" do
          expect(subject).wont_equal "Buffy Anne Summers"
        end

        describe "when the two-word last name is hyphenated" do
          let(:last_name) { "anne-summers" }

          it "does not return the capitalized full name" do
            expect(subject).wont_equal "Buffy Anne Summers"
          end
        end
      end
    end
  end

The output for these tests becomes messy:

  lab/minitest-post → ruby user_test.rb --verbose
  Run options: --verbose --seed 50406

  # Running:

  UserTest2::#full_name::when the user has a two-word last name#test_0001_does not return the capitalized full name = 0.00 s = .
  UserTest2::#full_name::when the user has a two-word last name::when the two-word last name is hyphanated#test_0001_does not return the capitalized full name = 0.00 s = .

  Finished in 0.001022s, 1956.9472 runs/s, 1956.9472 assertions/s.
  2 runs, 2 assertions, 0 failures, 0 errors, 0 skips

Output legibility is a common critique I hear about Minitest. At the same time, deep nesting makes reading both the files and the output difficult, no matter the framework.

Solving the tricky inheritance in Rails apps

Eric, from the Ruby on Rails Links Slack, pointed out the rails-minitest gem.

Maintained by the same people behind Minitest, rails-minitest provides a Minitest integration for Rails applications.

Its benefits include:

• It allows you to explicitly declare the type of class you’re testing.
• It resolves the inheritance shenanigans through that typing.
• It exposes extra spec-flavored expectations for Rails mailers, jobs, routing, and more.

How to install minitest-rails

The gem follows the versioning of Rails, so I added gem "minitest-rails", "~> 8.0.0" to my Gemfile.

minitest-rails comes with a handy installation generator - rails generate minitest:install- which adds all the necessary files to the application.

Be careful, though, the generator will overwrite your existing setup (much like the rails app:update command).

To prevent this, I dry-ran the generator with the --pretend flag, which shows all the changes the gem would make: rails generate minitest:install <APP_PATH> -p.

The changes in my application_system_test_case.rb were minimal:

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  some existing stuff

+  register_spec_type(self) do |desc, *addl|
+    addl.include? :system
+  end

  more existing stuff
end

The generator only added require "minitest/rails" and some parallelization configuration to my test_helper.rb.

Implicit and explicit test class typing

One of the benefits of the Minitest integration is that it lets me declare which class I’m testing with a describe block:

  describe User do
    ...
  end

Instead of:

  class UserTest < Minitest::Spec
    ...
  end

I don’t need to suffix my test class with Test (ie UserTest) and minitest-rails is able to infer the inheritance from the declared class.

I also can cast the type explicitly to help Minitest figure out which kind of test I want to run.

  describe User, :model do
    ...
  end

minitest-rails even lets me declare custom types and custom inheritance, but I haven’t (yet) figured out how this works (and where I could use it).

More spec-flavored expectations

minitest-rails also exposes extra expectations, specifically for mailers, jobs or routing. We don’t need to choose between expectations for testing models, and assertions for testing jobs. Expectations everywhere!

For instance, Rails’ default Minitest syntax would look like this:

  assert_enqueued_jobs 1 do
    NotifyUser.perform_later(user_id: user.id)
  end

And minitest-rails will look like this:

  must_enqueue_jobs 1 do
    NotifyUser.perform_later(user_id: user.id)
  end

The assertion becomes an expectation, harmonizing the syntax of my tests.

Yes, but…

While I managed to install the gem and update the declaration of my tests, one thing refused to work out of the box: mailers expectations.

Consider this test:

  describe NotifyUserJob, :job do
    let(:user) { User.new(first_name: "buffy", last_name: "summers") }

    it "sends a notification email to the user" do
      must_enqueue_email_with UserMailer, :notify, args: [user]
    end
  end

I used the new describe declaration for my test case, explicitly cast the :job type, and used the newly available must_enqueue_email_with expectation.

Easy, right? Well, no matter how I declared my test case, whether with implicit or explicit typing, must_enqueue_email_with raised a NoMethodError.

It means the Minitest::Rails::Expectations::ActiveMailer module isn’t mixed-in automatically.

I had to include Minitest::Rails::Expectations::ActionMailer within my test case to make this expectation work:

describe CalendlyEventsManagerJob, :integration do
  include Minitest::Rails::Expectations::ActionMailer

  ...
end

There’s no mention of this in the documentation, but I’ve found this comment in the ActiveJob expectations module:

This exists as a module to allow easy mixing into classes other than ActiveJob::TestCase where you might want to do job testing e.g. in an Active Record model which triggers jobs in a callback.

So it seems there is still some manual mixin to do, despite most of the inheritance being automatically handled.

Is it normal? Did I do something wrong? I don’t know (yet)!

Wrapping up

Well, this was a fun chase!

Let’s recap:

• Minitest::Spec also exposes let and subject.
• Both are lazily evaluated instance variables.
• With Minitest::Spec, you can nest describe blocks for better contextualisation.
• The minitest-rails gem provides a seamless integration of Minitest into Rails.
• The gem provides extra methods for an overall spec-flavored test suite.
• In my experience, it comes with some challenges around these extra expectations, which I solved by manually including the modules. But YMMV.

Big thank-yous to Cecile for pointing out the topic of let and subject, and to Eric for helping me out with setting-up the minitest-rails gem.

Before I dive in with a dedicated post about assertions, I want to cover this RSpec-style way of writing tests.

Minitest syntax flavors: a recap

As I wrote in my previous post, Minitest comes in multiple flavors:

• plain Minitest: def test_this_method
• Rails’ style: test "this method"
• and a spec system called Minitest::Spec: it "tests this method"

Each flavor changes the syntax we use to define our test files and our test examples. The changes in the DSL are minimal, in the sense that they all look familiar to Ruby developers.

Assertions are another matter.

While Rails adds a handful of assertions (mostly around database changes), both Minitest and Rails rely on the following paradigm:

Check that the expected assertion holds true against the actual result.

On the contrary, Minitest::Spec relies on the (RSpec-like) opposite paradigm:

Check that the actual behavior matches the expected result.

I know this sounds “po-tay-to, po-tah-to”, but bear with me for one sec.

Plain Minitest flavor:

  class UserTest < Minitest::Test
    def setup
      @user = User.new(first_name: "buffy", last_name: "summers")
    end

    def test_returns_the_full_name
      assert_equal "buffy summers", @user.full_name
    end
  end

Minitest::Spec flavor:

  class UserTest < Minitest::Spec
    before do
      @user = User.new(first_name: "buffy", last_name: "summers")
    end

    it "returns the capitalized full name" do
      expect(@user.full_name).must_equal "Buffy Summers"
    end
  end

For someone who comes from RSpec, this looks very familiar:

• Building a setup with before do ... end instead of setup do ... end.
• Defining test examples with it instead of test or def test_*.
• Expectations instead of assertions: expect(actual behavior).must_equal expected_result.

Using Minitest::Spec also allows me to organize my tests into describe blocks for different contexts.

  class UserTest < Minitest::Spec
    before do
      @user = User.new(first_name: "buffy", last_name: "summers")
    end

    it "returns the capitalized full name" do
      expect(@user.full_name).must_equal "Buffy Summers"
    end

    describe "when the user has a two-word last name" do
      before do
        @user = User.new(first_name: "buffy", last_name: "jane summers")
      end

      it "does not return the capitalized full name" do
        expect(@user.full_name).wont_equal "Buffy Jane Summers"
      end
    end
  end

Expectations can also be slightly abstracted away with the following syntax:

  it "returns the capitalized full name" do
    _(@user.full_name).must_equal "Buffy Summers"
  end

How to enable Minitest::Spec?

In Ruby applications

In plain Ruby files, there’s no need to configure anything at the application level. Minitest comes with both flavors, plain and spec, by default.

The only gotcha is that test classes need to inherit from Minitest::Spec instead of Minitest::Test. If you didn’t find this documented in the official repository, you’re not alone. It’s not documented at all. I found it in the source code while investigating why my spec-style tests weren’t working.

  class UserTest < Minitest::Spec
    ...
  end

In Rails applications

In Rails, I’ve found that you need to require "minitest/spec" and extend Minitest::Spec::DSL to the ActiveSupport::TestCase class.

Here’s an extract from my test_helper.rb file:

  # frozen_string_literal: true

  require "rails/test_help"
  require "minitest/spec"

  module ActiveSupport
    class TestCase
      extend Minitest::Spec::DSL
    end
  end

On the other hand, there’s no need to change the inheritance of your test classes to Minitest::Spec. The inheritance in Rails is already quite complicated on its own, though:

• Unit tests inherit from ActiveSupport::TestCase
• Integration tests inherit from ActionDispatch::IntegrationTest
• Unit tests for views (think helpers) inherit from ActionView::TestCase
• System tests inherit from ApplicationSystemTestCase

Sharp knives and gotchas

Ruby and Rails allow you to do some weird things at your own risk. Mixing setup do and before do in the same file is one of them.

Don’t do this. This is for educational purpose only.

In plain Ruby, setup and before will work alongside one another without a hurdle.

In Rails, both will work if used exclusively in one file. If you mix them in one file, you have two possible outcomes:

• If you use setup before before, your tests will run normally.
• If you use before before setup, your test will potentially fail because setup was not executed.

  require "test_helper"

  class UserTest < ActiveSupport::TestCase
    before do
      # will get executed
    end

    test "some method" do
      # will pass
    end

    describe "a nested context" do
      setup do
        # will not be executed
      end

      it "returns some result" do
        # will potentially fail
      end
    end
  end

Now that we’re more familiar with Minitest::Spec, we have access to a new way of writing assertions, such as must_equal, must_match, and others. I’ll cover those in a future post.

Wrapping up

I hope this post helped clarify the basics of the Minitest::Spec syntax.

The TL;DR is:

• Minitest::Spec is an extension of Minitest::Test.
• Minitest::Spec is the third main flavor of Minitest.
• Minitest::Spec provides a bridge between assertions and spec-style expectations.
• Adding Minitest::Spec to Ruby or Rails comes with some gotchas.

The third post of this series – More Minitest::Spec shenanigans – is live.

I’ve always used the other framework.

But earlier this year, I started working with a client whose application relied solely on QA instead of automated tests. In an effort to bring the team peace of mind during releases, I started adding tests to the most critical parts of the application.

Lured by the promise of speed and wide adoption, I suggested we try Minitest.

As I started working on writing my first tests, I hit an unexpected roadblock.

Minitest (lack of) onboarding

After writing several hundred tests, I can confidently say that Minitest’s biggest weakness is its onboarding. The information is so awfully scattered, so sparse and so obscure that it makes navigating your tax returns friendlier in comparison.

As a newcomer, I would have loved (let’s forget about love, I would have needed!) to get the main information right off the bat:

• What does Minitest do?
• Why does Minitest do what it does?
• How do you make Minitest do what it does?

Instead, Minitest’s official repository is a piece of writing more akin to Joyce’s Ulysses than to a technical documentation.

Programmers get welcomed with a list of footer-worthy links, some congratulatory quotes, and hints that you should get a mental health check for having ever used RSpec.

You have to scroll past this cruft to get the first useful nugget of information: a breakdown of Minitest main components.

Minitest 101

Minitest is a prominent testing framework for Ruby code. It’s the default testing framework embedded by default in Ruby and Ruby on Rails.

If you generate a new Rails app today, or if you have an existing app with no other test framework configured, you can run rails test, and Rails will find the test folder and check for test files.

Otherwise, it’s just a matter of adding gem 'minitest' to your Gemfile, and off you go. Minitest provides several components, each addressing a specific need. Here are a few:

• minitest/test provides a set of assertions to test your code.
• minitest/spec enables the use of RSpec-like matchers.
• minitest/mock is a lightweight mocking (and stubbing) library.

Minitest uses the concept of assertions which lets you verify that the expected result matches the actual result:

Check that this condition holds true.

Coming from RSpec, I’m used to the concept of expectations which take the opposite perspective of Minitest’s assertions:

This object should behave this way.

Minitest syntax flavors : everything, everywhere, all at once

One thing that slowed down my adoption is that Minitest offers multiple styles of syntaxes. You can write the same test in several ways, sometimes even mixing styles together. Each style lives in its own module or extension.

RSpec is either loved or hated for its DSL, but it gives me one major advantage: I don’t have to decide for every test which style to use. I use the standard and I move on.

With Minitest, though, I can choose from:

• the default syntax
• Rails’ custom syntax
• or Minitest’s spec syntax (which mimic RSpec’s style)

Let’s write some tests so you get my point.

Writing my first tests with Minitest

Let’s say I have this plain Ruby User class:

  class User
    attr_accessor :first_name, :last_name

    def initialize(first_name:, last_name:)
      @first_name = first_name
      @last_name = last_name
    end

    def full_name
      "#{first_name.capitalize} #{last_name.capitalize}"
    end
  end

And I want to write a simple test for it:

  require "minitest/autorun"
  require_relative "user"

  class UserTest < Minitest::Test
    def setup
      @user = User.new(first_name: "buffy", last_name: "summers")
    end

    def test_returns_the_full_name
      assert_equal "buffy summers", @user.full_name
    end
  end

In this case, I’m using plain Minitest. It’s the default syntax, with the simplest setup.

Several remarks:

• require "minitest/autorun" instructs Ruby to load Minitest and run the tests once the file is loaded.
• UserTest inherits from Minitest::Test, which allows me to use Minitest’s syntax.
• My test method def test_returns_the_full_name is prefixed with test_ which is a Minitest convention.
• The assert_equal method takes the expected result first, the actual result second.
• def setup; end lets me create my test setup before my code run, similar to RSpec’s before do ... end).
• I use ivars to access the objects I set up for my test examples.

Here’s the output for this first test:

  lab/minitest-post → ruby user_test.rb
  Run options: --seed 64661

  # Running:

  .

  Finished in 0.001239s, 807.1025 runs/s, 807.1025 assertions/s.
  1 runs, 1 assertions, 0 failures, 0 errors, 0 skips

If my test were to failed:

  lab/minitest-post → ruby user_test.rb
  Run options: --seed 22116

  # Running:

  F

  Failure:
  UserTest#test_returns_the_full_name [user_test.rb:10]:
  Expected: "buffy summers"
    Actual: "Buffy Summers"

  bin/rails test user_test.rb:9

  Finished in 0.001472s, 679.3478 runs/s, 679.3478 assertions/s.
  1 runs, 1 assertions, 1 failures, 0 errors, 0 skips

The same test, but in Rails

  class User < ApplicationRecord
    def full_name
      "#{first_name.capitalize} #{last_name.capitalize}"
    end
  end

  require "test_helper"

  class UserTest < ActiveSupport::TestCase
    def setup
      @user = User.new(first_name: "buffy", last_name: "summers")
    end

    test "returns the full name" do
      assert_equal "Buffy Summers", @user.full_name
    end
  end

What’s changed:

• My User now inherits from ApplicationRecord (because Rails).
• My test file starts with require "test_helper", which loads the Rails testing environment (database, fixtures, helpers, etc.)
• UserTest now inherits from ActiveSupport::TestCase, which inherits from Minitest::Test. This allows Rails to define additional assertions.
• Minitest’s test method definition (def test_returns_the_full_name) is now abstracted into the Rails DSL (test "returns the full name"). This syntax is just a method, test, that takes a description and a block as arguments (see the code source).

Since ActiveSupport::TestCase inherits from Minitest::Test, I can also mix and match syntaxes if I ever feel so inclined:

  require "test_helper"

  class UserTest < ActiveSupport::TestCase
    setup do
      @user = User.create(first_name: "buffy", last_name: "summers")
    end

    def test_returns_the_full_name
      assert_equal "buffy summers", @user.full_name
    end

    test "returns the user slug" do
      assert_equal "buffy_summers", @user.slug
    end
  end

Here, I use both Minitest syntax and the Rails DSL to define test examples in the same file. Does it work? Yep! Should I do it? I’d rather not!

But I wanted to show you that you can, even if you shouldn’t.

I did not even toggle minitest/spec which opens up a third syntax to set up and define your test examples. I’ll cover this in another post.

One thing I’m not showing here that you should know. In Rails, based on your type of test, you’ll want your test file to inherit from a different class:

• Unit tests, inherit from ActiveSupport::TestCase
• Integration tests, inherit from ActionDispatch::IntegrationTest
• Unit tests for views (think helpers), inherit from ActionView::TestCase
• System tests, inherit from ApplicationSystemTestCase

Wrapping up

As always, I intended this post to be short, and failed.

If you’re starting out with Minitest and feeling a bit lost, I hope this post helped you understand the basics.

The TL;DR is:

• Minitest is part of Ruby standard library.
• Minitest is part of Rails ActiveSupport.
• Minitest has several possible syntaxes to define your test examples.
• Minitest has a multitude of assertions (we’ll cover those in the next post).
• Minitest is obscure at first, but once you get the hang of it, it’s quite neat.

The second part of this series – What is Minitest::Spec – is now live!

Thank you to Cecile for her suggestions.

But lo and behold, the breakthrough happened!

Will it be Rust? Will it be JavaScript?

None of the above, my good sir! It’ll be Logo, a procedural language designed to teach children the basics of programming.

Why, though? Well, last week, my child’s new teacher told us he intended to introduce programming to the class. And I thought: “Ooooh, I might finally be able to explain to my children what I do for a living.”

So, I got very excited about it and down the rabbit hole I fell.

To make it extra fun, I designed a first 30-minute workshop with plenty of games.

Here’s my pitch to present the basic concepts to the kids:

Today, we’re going to control a computer. And to make a computer do cool things, we have to give it orders.

 

Orders are also called instructions.

 

An instruction can be short: “Take one step forward.”

 

Or it can be long: “Take one step forward, turn around, walk three steps hopping on your left foot while putting your right pinky in your nostril, fart loudly, laugh even louder, and do a cartwheel.”

 

When we put instructions together to make a computer do something, we build what’s called a program.

 

And a program is written in a language that the computer can understand: a programming language.

 

You, for example, speak French and a little bit of English. Well, the computer speaks C, Lisp, or Logo.

 

And that works out nicely, because today we’re going to talk to our computer in Logo.

I plan to have them team up to draw the initial of their first name using Logo instructions. I will get inspiration from Seymour Papert — one of the inventors of Logo — and have the kids use physical space to walk through and talk about the problem.

My current plan:

• Draw the two letters on the floor with masking tape.
• Build a set of cardboard jigsaw puzzle pieces that represent the instructions (in French).
• Have the kids pick the jigsaw pieces and assemble them on the tape to find the correct instructions and the correct order of operations.
• Have them type the instructions into the terminal and see if the output matches our expected result.
• Take a few pictures and do a quick write-up with them so they can present it in their classes.

Some ideas for my jigsaw puzzle pieces:

                        | \
+-----------------------+   \
|       avance 50            >
+-----------------------+   /
                        | /


       *******
     * tourne  *
    *  droite   *
    *    90    *
     *   |_   *
      *******

It’s been a long time since I got that excited about a side project! Let’s hope I won’t bore the kids to death!

Normally, I’d use the draper gem to build decorators. But the app I’m working on used an older and incompatible version of Rails.

So I built a minimal decorator from scratch, added a bunch of extra behaviors, only to end up abstracting all of these away. Follow along!

What I’m working with

My Teacher class has a handful of methods:

• A one-to-many relationship with the Student class.
• Two public methods: one that exposes the maximum number of students a teacher can teach to, and one exposing the available teaching places.

  class Teacher < ApplicationRecord
    has_many :students

    def maximum_number_of_students = 30

    def available_places
      (maximum_number_of_students <=> students.size).clamp(0..)
    end
  end

In my views, I want to display a table of teachers where the number of available places for each teacher is backed by a background colour.

# teachers/index.html.erb

<table class="table table-striped">
  <thead>
    <tr>
      <th>Name of the teacher</th>
      <th>Available places</th>
    </tr>
  </thead>
  <tbody>
    <% teachers.each do |teacher| %>
      <tr>
        <td><%= teacher.full_name %></td>
        <td class="<%= teacher.colour_coded_availability %>">
            <%= teacher.available_places %>
        </td>
      </tr>
    <% end %>
  </tbody>
</table>

I could write the Teacher#colour_coded_availability method in my model like so:

  class Teacher < ApplicationRecord
    has_many :students

    def maximum_number_of_students = 30

    def available_places
      (maximum_number_of_students <=> students.size).clamp(0..)
    end

    def colour_coded_availability
      case available_places
      when 0 then "bg-colour-red"
      else "bg-colour-green"
      end
    end
  end

However, models are not the place for methods generating CSS classes. Decorators are!

Drafting a decorator

My decorator should accept an instance of Teacher and expose the colour_coded_availability public method.

# app/decorators/teacher_decorator.rb

  class TeacherDecorator
    attr_reader :teacher

    def initialize(teacher:)
      @teacher = teacher
    end

    def colour_coded_availability
      case teacher.available_places
      when 0 then "bg-colour-red"
      else "bg-colour-green"
      end
    end
  end

Now, I can instantiate my decorator and use it in my views:

# app/controllers/teachers_controller.rb
  class TeachersController < ApplicationController
    def index
      @teachers = Teacher.all.map { TeacherDecorator.new(teacher: _1) }
    end
  end

# teachers/index.html.erb
  <table class="table table-striped">
    <thead>
      <tr>
        <th>Name of the teacher</th>
        <th>Available places</th>
      </tr>
    </thead>
    <tbody>
      <% @teachers.each do |teacher| %>
        <tr>
          <td><%= teacher.full_name %></td>
          <td class="<%= teacher.colour_coded_availability %>">
              <%= teacher.available_places %>
          </td>
        </tr>
      <% end %>
    </tbody>
  </table>

When I can call teacher.colour_coded_availability in my views, the method retrieves a CSS class and adds it to the HTML <td> tag.

But if I were to run this code as is, I’d get a beautiful NoMethodError. Why?

My views do not handle instances of Teacher anymore. They handle instances of TeacherDecorator. So, when I’m calling the public methods defined on Teacher, the decorator doesn’t know what to do with them.

My decorator needs to be able to handle both its own public methods and the public methods defined on the underlying record (Teacher, in this case).

And we do that by using Ruby’s method_missing.

Ruby’s method_missing to the rescue

method_missing is how Ruby handles method calls made on objects where said methods are not defined. Ruby passes the method call along the ancestry chain until it can either resolves it or raises a NoMethodError.

When I call @teacher.full_name, I want my decorator to rescue the NoMethodError, and forward #full_name to the underlying instance of Teacher.

To do that, I need to re-open Ruby’s method_missing, add a custom behavior, then allow method_missing to run its normal course.

class TeacherDecorator
  attr_reader :teacher

  def initialize(teacher)
    @teacher = teacher
  end

  def availability_as_background
    case teacher.max_number_of_students <=> teacher.available_places
    when -1 then "background-danger"
    when 0 then "background-warning"
    when 1 then "background-success"
    end
  end

  private

  def method_missing(method, ...)
    return teacher.public_send(method, ...) if teacher.respond_to?(method)

    super
  end

  def respond_to_missing?(name, include_private = false)
    teacher.respond_to?(name) || super
  end
end

In this example, I keep the original signature of Ruby’s method_missing.

The only thing I tweak is forwarding the method call to the underlying teacher. I only forward it if the teacher responds to the method. Then, I let Ruby resume its original behavior ¹.

Now, @teacher.full_name is properly forwarded to the underlying instance of Teacher.

What would be cool now, is to allow other decorators to share this behavior.

Normalizing the behavior to create other decorators

One way to gather default behavior shared across various decorators is to rely on inheritance. I can create an ApplicationDecorator whose job is to handle instantiation, and forwarding method calls to the underlying record.

Then, I can have my TeacherDecorator inherit from the ApplicationDecorator.

class ApplicationDecorator
  def initialize(record)
    @record = record
  end

  private

  attr_reader :record

  def method_missing(method,...)
    if record.respond_to?(method)
      record.public_send(method, ...)
    else
      super
    end
  end

  def respond_to_missing?(name, include_private = false)
    record.respond_to?(name) || super
  end
end

class TeacherDecorator < ApplicationDecorator
  attr_reader :teacher

  def availability_as_background
    case teacher.max_number_of_students <=> teacher.available_places
    when -1 then "background-danger"
    when 0 then "background-warning"
    when 1 then "background-success"
    end
  end

  private

  alias_method :teacher, :record
end

My TeacherDecorator doesn’t need to bother about its initialization since it’s handled by the parent ApplicationDecorator. The only thing I added, is the ability to reference the record as teacher so it’s clearer what kind of record we’re working with.

Ensure Rails default behavior works well

Some Rails native helpers will have a hard time handling my decorator.

Consider this code:

  `edit_teacher_path(@teacher)` # => Should generate teachers/1/edit

But if @teacher references an instance of my TeacherDecorator, the generated path is teachers/#TeacherDecorator/edit.

How do I make my decorator integrate with Rails default behavior?

I can re-open the to_param method which is responsible for turning (among other things) a record into its id, and delegating its behavior to the record.

class ApplicationDecorator
  def initialize(record)
    @record = record
  end

  delegate :to_param, to: :record

  private

  attr_reader :record

  def method_missing(method,...)
    if record.respond_to?(method)
      record.public_send(method, ...)
    else
      super
    end
  end

  def respond_to_missing?(name, include_private = false)
    record.respond_to?(name) || super
  end
end

Of course, forwarding every Rails default behaviors to the underlying record is not a great strategy (too much complexity). So, how should I do it?

Use Ruby standard SimpleDelegator

SimpleDelegator provides the means to delegate all supported method calls to the object passed into the constructor.

This means that by using SimpleDelegator, I can remove the initialization and the delegation logics from my ApplicationDelegator.

require "delegate"

class ApplicationDecorator < SimpleDelegator ; end

Everything is abstracted away. And it just works™. @record is not available anymore for my TeacherDecorator to reference, but SimpleDelegator exposes a __getobj__ that works exactly as my previous @record ivar.

Final implementation

Here’s what I ended up with:

require "delegate"

class ApplicationDecorator < SimpleDelegator ; end

class TeacherDecorator < ApplicationDecorator
  def availability_as_background
    case teacher.max_number_of_students <=> teacher.available_places
    when -1 then "background-danger"
    when 0 then "background-warning"
    when 1 then "background-success"
    end
  end

  alias_method :teacher, :__getobj__
end

That’s it! A 30-minute minimal decorator in plain Ruby.

Cheers,

Rémi - @remi@ruby.social

This is an intermediate-level post. If you’re unfamiliar with RSpec, start at the beginning of the series.

A typical test file

Let’s draw a quick books_controller_spec.rb that checks the behavior of a PATCH action.

  RSpec.describe BooksController do
    let(:book) do
      Book.create(title: "The Long Way to a Small, Angry Planet", blurb: nil)
    end

    describe "PATCH /books/:id" do
      let(:action) { patch :update, params: }
      let(:params) { { id: book.id, book: { blurb: } } }
      let(:blurb) do
        "Fleeing her old life, Rosemary Harper joins the multi-species crew of the Wayfarer as a file clerk, and follows them on their various missions throughout the galaxy."
      end

      it "returns an :ok response" do
        action

        expect(response).to have_http_status(:ok)
      end

      it "changes the blurb of the book" do
        action

        expect(book.reload).to eq(blurb)
      end

      it "redirects the user to the /show page" do
        action

        expect(response).to redirect_to("/books/#{book.id}")
      end
    end
  end

This test file is pretty straightforward:

• The setup creates a book with a title and no blurb.
• The tests verify that the BooksController#update method works as intended: update the attributes, return the correct response, and check for final redirection.

One question, though. Can you tell how RSpec actually runs this test?

The lifecycle of a test file

Test files are separated into two concepts: example groups and examples.

Example groups are a recursive entity in RSpec. They represent:

• the logic within RSpec.describe BooksController do,
• the logic within describe "PATCH /books/:id" do or context "when something is different" do.

Examples represent the logic within it blocks. And it blocks encapsulate expectations.

RSpec.describe BooksController do                 # <-- top-level example group
    describe "PATCH /books/:id" do                # <-- nested example group
      it "returns an :ok response" do             # <-- example
        expect(response).to have_http_status(:ok) # <-- expectation
      end
    end
  end

When running a test file, RSpec will:

• run the top-level example group,
• within run, run_examples,
• if the examples are nested example groups, it will run recursively,
• until RSpec can run an actual example, i.e. an it block.

Next, for each example (it blocks), RSpec does a handful of things ¹:

• run_before_context_hooks: creates the instance variables (your let) and executes before blocks,
• runs the expectations,
• generates the report,
• run_after_context_hooks: rollbacks the database and resets the ivars.

In layman’s terms, it means that for each it, RSpec runs anew all your let and before blocks, only to discard them all at the end of the process.

Let’s check our book instance in different it groups.

  it "returns an :ok response" do
    p book.id # => 1
  end

  it "changes the blurb of the book" do
    p book.id # => 1
  end

  it "redirects the user to the /show page" do
    p book.id # => 1
  end

At first, I would assume that my book is always the same book. And yet.

Let’s check the memory pointer associated with my book.

  it "returns an :ok response" do
    p book.object_id # => 56100
  end

  it "changes the blurb of the book" do
    p book.object_id # => 56220
  end

  it "redirects the user to the /show page" do
    p book.object_id # => 56350
  end

Uh, what?

What it tells us is that while each book looks identical at the database level (same id), each Ruby object we’re looking at is different (different memory pointer object_id).

So, RSpec recreates new Ruby objects for every it block.

But what about book always having the same id?

Most Rails integration of RSpec offers the ability to wrap examples in a database transaction ², meaning that once your example has run, the database rolls back to its original state. Hence why you always have book with the same id.

The TL;DR is that the more it blocks you have, the more RSpec has to evaluate your setup, fill your test database with new records, instantiate new Ruby objects, and discard all of it.

While this decouples testing data from the order of test execution, for a lot of everyday tests, this is a tad overkill and slows your test suite down.

Ok, Rémi? So, how do we fix it?

Aggregate examples and cut setup time

There’s a very simple thing you can do, to cut setup time big time: aggregate your expectations in fewer examples.

  RSpec.describe BooksController do
    let(:book) do
      Book.create(title: "The Long Way to a Small, Angry Planet", blurb: nil)
    end

    describe "PATCH /books/:id" do
      let(:action) { patch :update, params: }
      let(:params) { { id: book.id, book: { blurb: } } }
      let(:blurb) do
        "Fleeing her old life, Rosemary Harper joins the multi-species crew of the Wayfarer as a file clerk, and follows them on their various missions throughout the galaxy."
      end

      it "successfully updates the book", :aggregate_failures do
        action

        expect(response).to have_http_status(:ok)
        expect(book.reload).to eq(blurb)
        expect(response).to redirect_to("/books/#{book.id}")
      end
    end
  end

Sure, you lose some legibility, but instead of having RSpec build your test setup three times, you only do it once. I’ll try and post an update with some benchmarks later on, but this seems quite a big gain especially when used across a whole test suite.

Note that I added the :aggregate_failures flag to my it block. This tells RSpec to not fail fast, to run all my expectations in the block, and to bundle all my failures together.

That’s it! Hope you liked this lengthy yack shaving, as much as I liked writing it!

Cheers,

Rémi - @remi@ruby.social

PSS: Many thanks to Sunny for sending me down this rabbit hole!