DEV Community: Povilas Jurčys

A New Cop in Town: rubocop-rspec_parity

Povilas Jurčys — Wed, 28 Jan 2026 10:05:25 +0000

Let me tell you a story about coverage reports lying to me.

Years ago, at a company with a huge Ruby codebase, I stared at green coverage numbers like a fool. “Coverage says yes, reality says no.” Controllers with ten services inside, one happy-path test, and everything technically covered. Meanwhile, bugs were popping up like popcorn in the background.

So I wrote a tiny linter. Just enough to point out the obvious: if you wrote a public method, you better have a test for it. And not just a test that runs the line — a test that actually checks behavior.

Fast forward a bit, I’m on my personal projects, doing vibe coding. That’s where AI writes the code and I review it. Fun, right? Until you realize the AI has very optimistic testing habits. It adds methods like it’s confetti, but forgets the tests. Or writes shallow ones. Or hits one branch and calls it a day.

I’ve had enough. Again. And again. And again. Four times to be exact. Finally, I thought, maybe I should just make this a gem. So here it is: rubocop-rspec_parity.

What it does (in plain human words)

Public methods are promises.
Tests are the proof.

Think of it like a little courtroom for your code. Your methods swear they’ll behave. Your tests show up to testify. And if there’s no testimony? The cop yells.

Here’s what it actually checks:

Are your public methods actually tested? (No hiding behind “covered lines”)
Are all branches tested? if, else, || — nothing escapes
Did someone commit a “bug fix, no time to test” trick again? The cop knows

Basically, it’s your spec’s annoying little friend. Instant feedback, no excuses, no waiting for CI. It’s like a mirror for your code: you think it’s okay, until it tells you otherwise.

It doesn’t invent rules. It doesn’t force new conventions. It just makes sure you follow the ones you already claim to follow. If you believe tests matter, this gem is like that one coworker who won’t let you sneak out early — except way less passive-aggressive.

Who this is for

Solo devs doing vibe coding who want AI output to be less… optimistic
Ruby teams that care about test quality and want fast feedback
Anyone who’s ever stared at coverage numbers and muttered, “sure… yeah… that counts”

Quick example

# bad
class UntestedClass # file: app/models/untested_class.rb
  def untested_method = 'foo'
end
# no test at spec/model/untested_class_spec.rb

# good
class TestedClass # file: app/models/tested_class.rb
  def tested_method = 'foo'
end
RSpec.describe TestedClass # file: spec/models/tested_class_spec.rb
  describe '#tested_method' do
    it { expect(subject.tested_method).to eq('foo') }
  end
end

See? Simple, obvious, yet people miss it all the time.

TL;DR

rubocop-rspec_parity is out. It’s new. It’s your spec’s nagging friend. It works. Drop it in your Gemfile, require it in .rubocop.yml, and your tests will start behaving like adults.

Public methods are promises.
Tests are the proof.

GitHub: https://github.com/povilasjurcys/rubocop-rspec_parity

Side note: yes, I had a tiny AI whispering ideas while I wrote this post. But I promise the coffee, the bugs, and the frustration are 100% human. ☕🐛

[Boost]

Povilas Jurčys — Mon, 24 Nov 2025 05:29:58 +0000

How I Ended Up Building With GitHub Copilot (the Remote One) And Why It Still Feels Kinda Wild

Povilas Jurčys ・ Nov 22

#ai #vibecoding #productivity #development

How I Ended Up Building With GitHub Copilot (the Remote One) And Why It Still Feels Kinda Wild

Povilas Jurčys — Sat, 22 Nov 2025 16:57:20 +0000

A few months back, I wasn’t even that into AI. I thought it was just another tech phase that would fade, like fidget spinners or those standing desks everyone bought and now use as laundry racks. But then I started looking for something stupidly specific - a way to work on my side project without sitting at my computer. Like, actually making progress while waiting in a shop line or sitting on the bus thinking about some random UI tweak.

I wanted something I could talk to, drop ideas into, and it would just… do it. Quietly. No drama. No "permission to run rm -rf?" nonsense.

And then I found GitHub Copilot - the remote version, the one with the web UI that actually opens PRs for you.

I swear, I don’t know what GitHub people did here, but this thing is on a different wavelength. And somehow it matches mine.

The Moment I Realized This Thing Was Unreal

There was this completely unserious moment where I typed “also make this page stunning.” It was half a joke. Like telling your friend “lol just redesign it for me.”

But then Copilot actually redesigned the page. Properly. With taste.
I was staring at my screen like:
ok… what just happened?

Then I asked it to “document all UI changes so I can use them as a style guide” and it wrote a full-on design language for the rest of my app. Just casually.

That was my jaw-on-the-floor moment.

If you don’t believe me, go check the Traquility mood tracker app I managed to pull together in under a year. I’m not saying it’s the best mood tracker ever, but… it kinda slaps.

How I Actually Use It (Honestly, Everywhere)

Before Copilot, I shoved ideas into GitHub Projects or whatever was closest at the moment. Now I just type them straight into Copilot itself. Doesn’t matter where I am. Standing in line, bored on the couch, half awake in the morning - I throw tasks at it like I’m feeding pigeons.

Then I go live my day.

Later, when I have an hour or two, I open up the PRs Copilot prepared.
Some I accept. Some I adjust. Some I look at and say “nope, not today buddy.”

It’s become this weird ritual. I use it every day. Sometimes every hour.

When Copilot Acts Like a Very Confident Intern

It’s not perfect. It has moments where it behaves like a junior dev who’s extremely sure of himself but also extremely wrong.

Like the time my RSpec specs were failing because of a missing constant. The actual fix was basic - update the namespace, correct the code. But Copilot? It decided to introduce a mock for the non-existent class.
Amazing. Incredible. Completely useless.

Or the time it generated a PR saying “page now communicates better with the user” and included a screenshot of a blank white page with a crash report and a full backtrace. I stared at it thinking “uhhh… improved how exactly?”

Luckily the screenshot was just wrong. The real change was good. But still - that moment lives in my head.

The UI? Mostly Copilot. Thank God.

I’m not a designer. I try. Really. But my natural style leans toward “functional and aggressively ugly.” Copilot basically saved me from myself.

It worked surprisingly well with my Turbo-Hotwire-Stimulus setup, even though it tried to introduce React a couple times like a persistent friend recommending the same TV show over and over. With some nudging, it figured things out.

It built full features. Entire pages. Proper workflows.
Again - if you think I’m exaggerating, look at the app yourself.

One thing I do now is ask Copilot to create a feature proposal first. Like a blueprint. Then I correct it. Then I say “ok, now implement this.” This cuts down on 90 percent of the chaos.

Tests? Nope. I Don’t Trust It There.

I love tests. Almost too much. But AI tests? They feel like those fake steering wheels you give kids in the backseat. Looks real. Does nothing.

Copilot writes tests but I treat them as a rough checklist. After it pushes a feature, I go in and fix translations, clean database schema things, and rewrite tests so they test actual behavior.

TDD completely falls apart with this workflow. At least for now.

Why Copilot Just Works Better For Me

Compared to other AIs I tried - Claude, ChatGPT, even Copilot running locally - the remote version is sharper. More focused. Less annoying. It doesn’t nag me. It doesn’t panic. It doesn’t ask for permission to run dumb commands. It doesn’t lose confidence and float into irrelevant topics.

It just works until it stops. No drama.

That alone is worth the 10 bucks a month.

To the Skeptics

Look, I’m not here to convert anyone. Haters gonna hate. I’m mostly bragging because I somehow slipped into this weird AI-assisted flow and now it feels like an extension of me. I don’t even think like a programmer anymore. More like a… creator or manager who gives orders and watches magic happen.

If you’re skeptical - I get it. I was too. I thought AI was hype. Now I use it for basically everything and I have no desire to go back.

Just know that the remote Copilot is paid. Nothing crazy. But yeah - not free.

Final Thoughts

If you’re curious, give it a shot. If not, no worries. But for me, this tool changed how I build things. It made side projects portable. It made me faster. It filled in the skills I don’t have. And it kept surprising me in the best possible ways (and sometimes the worst ones, but that’s part of the charm).

A huge chunk of what I built in the past months? Copilot helped with that. A LOT of it. And somehow, instead of making me feel lazy, it made me feel more creative.

Not bad for something that started as “I just want to work in a bus.”

Quick side note: yep, I wrote this with AI help. Kind of poetic, honestly.

How to use custom gems without changing the Gemfile

Povilas Jurčys — Wed, 22 May 2024 08:01:47 +0000

Intro

It was a typical Tuesday. My warm coffee sat on the table, and my rubber duck was in front of me. I remembered that last week I had been investigating a bug and knew which method I needed to look into for troubleshooting. There was something wrong with one of the arguments.

I updated my branch, ran bundle install, and started the server. I put binding.pry in that method to check the argument. Sure enough, the argument wasn't supposed to reach the method I was investigating. I needed to find out who was calling this method and how the argument was being built. In the pry debug console, I typed up and suddenly got an undefined method "up" error.

Did I make a typo? No. But there had been some gem updates - maybe my favorite pry-byebug gem had major changes? I opened the Gemfile, and it was gone! I found a commit with the description "Do not use pry-byebug because it slows down the app." You know what - I'll take a slower app if it allows me to develop faster!

I’m sure you have your own stories about how certain development gems are considered a disadvantage for the project, even though they help you work more efficiently.

Well, I have good news for you - you can still use any gem you want in your development environment without changing the project codebase.

Gemfile.personal technique

The cleanest solution I've found is to use a separate Gemfile.personal and a custom Gemfile path. This way, you can use it in any project without modifying the project code at all.

1. Add the `Gemfile.personal` to the project's root directory

# /path/to/your_ruby_project/Gemfile.personal
eval File.read('Gemfile') # use all gems from Gemfile

gem 'personal-gem1'
gem 'personal-gem2'

2. Install gems using the `Gemfile.personal` file

When installing gems, use the --gemfile option:

bundle install --gemfile=Gemfile.personal

To keep Gemfile.personal.lock synchronized with Gemfile.lock, copy the contents of Gemfile.lock to Gemfile.personal.lock whenever you update your personal gems. Use the following script:

cp Gemfile.lock Gemfile.personal.lock && \
bundle install --gemfile=Gemfile.personal

3. Globally ignore `Gemfile.personal` and `Gemfile.personal.lock`

touch ~/.gitignore
echo "Gemfile.personal\nGemfile.personal.lock" >> ~/.gitignore
git config --global core.excludesFile '~/.gitignore'

This will apply to all projects, so you don't need to update each project's .gitignore separately.

4. Update the BUNDLE_GEMFILE environment variable

If you want to use your custom Gemfile occasionally, you can include BUNDLE_GEMFILE=Gemfile.personal before every command, like this:

BUNDLE_GEMFILE=Gemfile.personal bundle exec rails console

But I find that annoying. Instead, I use bash/zshell aliases to make my life easier:

# ~/.bashrc
alias be="bundle exec"

# The letter "c" stands for "custom"
alias bec="BUNDLE_GEMFILE=Gemfile.personal be"

Now, I can switch Gemfiles by adding or removing one letter:

be rails console # uses the default Gemfile
bec rails console # uses Gemfile.personal

However, this option is not for everyone. If you want to always use your custom Gemfile.personal, you could also set this value globally by adding this line at the end of your ~/.bashrc or ~/.zshrc file:

# ~/.bashrc or ~/.zshrc
export BUNDLE_GEMFILE=Gemfile.personal

You could use a .env file to expose this variable per project:

# /path/to/your/project/.env
BUNDLE_GEMFILE=Gemfile.personal

Final Thoughts

Using the Gemfile.personal technique allows you to customize your development environment without affecting the rest of the team. It’s a flexible solution that keeps the project’s codebase unchanged while giving you the tools you need to work efficiently. With a few simple steps, you can set up your environment to include your preferred gems, making debugging and development smoother and faster. This approach ensures that your workflow remains uninterrupted and tailored to your preferences, all without impacting the project's performance or stability. Happy hacking!

FactoryBot: the secret weapon called @overrides

Povilas Jurčys — Tue, 16 Apr 2024 03:30:54 +0000

Intro

FactoryBot is a great tool that simplifies test setup logic by hiding object build complexity within factory files. Thus, instead of repeating the same model logic again and again, you simply write something like this:

create(:restaurant, :fancy)
create(:restaurant_order, :in_fancy_restaurant)
create(:dish_order, :in_fancy_restaurant, :steak)

Properly written factories look good and are more descriptive than a bunch of code lines that just build valid models. The factory will do all the dirty work for you and hide the model build login inside the factory file. The downside: in many cases, you are also the person who needs to create and maintain that good-looking-from-outside factory file.

As with every tool, there are some side effects that you should be aware of if you do not want to ruin your day thinking about weird things happening to you and what's the meaning of life.

In this post, we are going to focus on one of such challenges. We will talk about complex many-to-many, cross-dependent factories and how to properly create them.

So, how hard it can be to create a factory with multiple dependencies? Easy!.. If you know how to use factory bot internals in your favor. Read on and I will show you how!

Problem with many-to-many dependencies

Everything is fun and games until you introduce many-to-many associations. Imagine an Uber Eats-like app where you can choose your lunch from various restaurants and place orders. Each restaurant has its dishes and separate orders - you can't make a single order with dishes from different restaurants. It is a quite common limitation. A simplified relationship between models will look like this:

class Restaurant
  has_many :dishes
end

class Order
  belongs_to :restaurant
end

class Dish
  belongs_to :restaurant
end

class OrderedDish
  belongs_to :order
  belongs_to :dish
end

And factories will look like this:

FactoryBot.define do
  factory :restaurant do
    name { 'TastyPizza' }
  end

  factory :order do
    restaurant { association(:restaurant) }
  end

  factory :dish do
    restaurant { association(:restaurant) }
  end

  factory :ordered_dish do
    order { association(:order) }    
    dish { association(:dish) }
  end
end

At first glance, it looks plain and simple, but hold your horses! Look closer to the :ordered_dish factory. There are hidden associations in it and they work incorrectly. When you create :ordered_dish you will also create one Order record, one Dish record, and... wait for it... two Restaurant records:

ordered_dish = create(:ordered_dish)
order_restaurant = ordered_dish.order.restaurant
dish_restaurant = ordered_dish.dish.restaurant

order_restaurant == dish_restaurant #=> false

It's like ordering KFC's chicken wings from McDonalds. It would be nice, but it's not how life works.

The simplest solution involves modifying our factory to reuse the restaurant instance from one of the associations, as shown below:

factory :ordered_dish do
  order { association(:order) }    
  dish { association(:dish, order.restaurant) }
end

This is great, but there is a catch: each developer has to know that you are not allowed to pass the custom dish attribute otherwise you will end up with the same two-Restaurants-instead-of-one problem:

dish = create(:dish)
ordered_dish = create(:ordered_dish, dish: dish)

dish.restaurant == ordered_dish.order.restaurant #=> false

This happens because passing the custom dish attribute does not trigger the dish { association(:dish, order.restaurant) } block, so the restaurant instance is not shared. You could make a recursive dependency like this:

factory :ordered_dish do
  order { association(:order, restaurant: dish.restaurant) }    
  dish { association(:dish, order.restaurant) }
end

In this case, it will work nicely as long as you pass custom order or dish, but it will give you a "stack level too deep" error if you try to create ordered_dish with default associations:

create(:ordered_dish) # => error :(

It looks like there is no silver bullet in this situation. You have to choose and no choice is perfect. If only we could know in advance which attribute is non-default and passed by the user...

And there is a way how to know this.

Using @overrides for two-way dependencies

Have you ever wondered how FactoryBot DSL works? I mean, you write the name of an attribute or association and you do not get an undefined method error. Well, FactoryBot developers put a lot of thought into that, used the method_missing technique, and ensured that their DSL handler which they call Evaluator has almost zero predefined methods. Here is a stripped version of that class:

class FactoryBot::Evaluator
  class_attribute :attribute_lists

  private_instance_methods.each do |method|
    undef_method(method) unless method.match?(/^__|initialize/)
  end

  def method_missing(method_name, ...)
    if @instance.respond_to?(method_name)
      @instance.send(method_name, ...)
    else
      SyntaxRunner.new.send(method_name, ...)
    end
  end
  # ...
end

So there are only a few methods that you can't use in your factories. If you need to access some Evaluator-specific variables, you need to use instance variables. I do not like using instance variables, but given the context - I understand why this is an exception. I'm telling you this because I would like to introduce you to the @overrides instance variable that you could use to check which attributes were customized. Its name is self-explaining. It's a Hash that contains all the custom attributes that were passed when you create a factory.

create(:oder_dish, order: create(:order))
# @overrides will be { order: #<Oder:0x00007f...>}

Now, with the help of @overrides, we could check which attribute was customized and assign restaurant accordingly. The code won't be as pretty as before, but it will work like a charm:

factory :ordered_dish do
  order do 
    restaurant = @overrides[:dish]&.restaurant
    restaurant ||= association(:restaurant)

    association(:order, restaurant: restaurant) }
  end

  dish do
    restaurant = @overrides[:order]&.restaurant
    restaurant ||= association(:restaurant)

    association(:dish, restaurant: restaurant) }
  end
end

You can make this code a bit cleaner if you are OK with using transient attributes:

factory :ordered_dish do
  transient do
    restaurant do 
      @overrides[:order]&.restaurant ||
      @overrides[:dish]&.restaurant ||
      association(:restaurant)
    end
  end

  order { association(:order, restaurant: restaurant) }    
  dish { association(:dish, restaurant: restaurant) }
end

The final result is longer, but it does not have any complex logic in it. It simply checks multiple places for restaurant presence. Most importantly, it makes the factory work flawlessly no matter how you use it. And this is the most important part. We did the impossible - we managed to deal with the cross-dependency challenge.

Summary

In our journey with FactoryBot, we've explored how to tackle complex scenarios like many-to-many associations and cross-dependencies between factories. It all started with a simple idea of creating clean, reusable factory code to streamline test setup.

We learned that creating factories isn't just about writing straightforward code. When dealing with interchained relationships things can get tricky. For instance, we discovered the problem of accidentally creating duplicate records when we shouldn't.

To overcome this challenge, we had to dive deep into FactoryBot's internals. We explored using the @overrides instance variable, which helped us identify customized attributes passed during factory creation. By leveraging this knowledge, we were able to craft factories that adapted intelligently to different scenarios.

Remember, even in the world of coding, challenges are opportunities in disguise. By understanding the tools at our disposal and delving into their inner workings, we can conquer any coding puzzle that comes our way. So, keep exploring, keep learning, and keep building!

Until next time, happy coding!

You don't know RSpec: intro to RSpec for RSpec professionals

Povilas Jurčys — Thu, 01 Feb 2024 12:54:13 +0000

Intro

Welcome to a journey through RSpec's fundamental tools! RSpec is a popular testing framework for Ruby, designed to make writing and maintaining tests more intuitive and efficient. The majority of developers are already familiar with the basic RSpec helpers such as describe, it, let, and subject.

In this article, we will focus on each of these seemingly simple yet powerful methods, uncovering their nuanced functionalities. Prepare to be astonished as we unveil the richness of RSpec's toolkit, empowering you to write tests that not only validate your code but also enhance your development experience.

Do you know `describe`?

Like Big Bang starts with a BANG!, so RSpec description starts with the RSpec.describe. But do you know that there are 7 alternative ways you can "describe" your example group? 3 of them are identical and might be more familiar to you:

describe
context
example_group

The other 4 describe-like methods not only describe example groups but also add additional metadata. These are:

fdescribe
fcontext
xdescribe
xcontext

Let's focus on each of those groups separately.

`describe`, `context`, and `example_group`

You read it right - context and describe (and less known example_group) from the technical perspective are the same. It has differences for us, developers only. describe is mostly used to specify the class or method you want to test, and context is used for defining different conditions in which the method is tested.

So, everything you can do with describe, you can also do with context or example_group. For instance, you can initiate your spec with a context instead of describe like this:

RSpec.context User do
  describe '#first_name' do
    # ...
  end
end

or like this

RSpec.example_group UserComment do
  context '#body' do
    # ...
  end
end

I do not recommend doing so, but it's nice to know the possibilities.

`fdescribe` and `fcontext`

Prefix f in fdescribe and fcontext means "focus". It's a shortcut for:

describe 'something', focus: true do #...

If you have fdescribe in your spec file, the rspec command will run tests only in the fdescribe group and skip other specs.

`xdescribe` and `xcontext`

Prefix 'x' in xdescribe and xcontext means that the given example block will be skipped. It's a shortcut for:

describe 'something', skip: true do # ...

The rspec command will run all specs except those defined in the example group described with xdescribe or xcontext.

Do you know `it`?

If the idea of having 7 default ways to describe your spec seems overwhelming, prepare to be amazed: it has 12! Here is a list of all methods, along with their aliases grouped together:

it, specify, example
focus, fit, fspecify, fexample
skip, xit, xspecify, xexample
pending

As with describe there are 3 tag-free aliases for defining example blocks. Then there are some aliases for "focus" and "skip" tags. Then there is a pending that runs your test example without reporting any failures.

Custom aliases for `describe` and `it`

You are now familiar with many aliases for starting your describe and it block. But you can go even further and create custom aliases. Here is how to do it:

RSpec.configure do |config|
  config.alias_example_group_to :having, my_tag: true
  config.alias_example_to :i_would
end

RSpec.describe Foo do
  having 'my custom describe alias' do
    i_would { expect(:life).to be(:easy) }
  end
end

This opens a new world of possibilities to have specs tailored to your needs and business language. Even though: don't overuse it.

Do you know `let`?

let looks so simple, but its shy look hides complexities many of us can't imagine. I wrote a dedicated post just for let called Deep Dive into RSpec's let Helper. When we work with let daily we do not hesitate to ask: "What is let?". Like, yeah, it's a helper, but... What is let from the ruby perspective? Is it a variable? Lambda?

The answer is: let is a method.

And why is that important? Because you can call super() in let and it supports all the context/describe hierarchy. Let me explain this in rspec language:

RSpec.describe 'Playing with `let`' do
  let(:foo) { 'foo' }

  it { expect(foo).to eq 'foo' }

  context 'with capitalized value' do
    let(:foo) { super().upcase }

    it { expect(foo).to eq('FOO')
  end
end

As you can see, we redefined the second let(:foo) using super(). This nice technique is handy when you have a huge initial let Hash and you want to test cases with tiny modifications. For example, in controller tests when you send a lot of params and you want to test what will happen when you send the same data but with one missing value?

But there is another interesting side effect of let being a method. You can use let and def interchangeably. So we can write previous spec like this too:

RSpec.describe 'let vs def' do
  let(:foo) { 'foo' }

  it { expect(foo).to eq 'foo' }

  context 'with capitalized value' do
    def foo
      super().upcase
    end

    it { expect(foo).to eq('FOO')
  end
end

`super()` and `describe`

So let is a method that supports super(). When you use super() within a let block, it retrieves the value from the parent describe block. This hints at something crucial: underneath, each describe block is executed in the class context that inherits from its parent describe block. This insight sheds light on the powerful inheritance mechanisms at play within RSpec's structure, offering a deeper understanding of how specifications are organized and executed.

Do you know `subject`?

Have you ever wondered if named subject is the same as let? How about subject without the name? The short and boring answer is yes, in many cases the subject is the same as let. If you are curious about those cases, when the subject is not the same - read on!

Unnamed `subject` VS `let`

subject { ... } without the name is simply shortcut for let(:subject) { ... }. What it means, is that you can write this and it will work:

RSpec.describe 'subject vs let' do
  subject { 'foo' }

  it { expect(foo).to eq 'foo' }

  context 'with super in let(:subject)' do
    let(:subject) { super().upcase }

    it { expect(subject).to eq('FOO')
  end

  context 'with super in subject' do
    subject { super().upcase }

    it { expect(subject).to eq('FOO')
  end
end

Mindblowing!

But things become much more complicated when you add the name to your subject

Complexities of the named `subject`

However, there is one limitation: you are not allowed to call super() in a named subject. So this will not work:

RSpec.describe 'named subject' do
  subject(:foo) { 'foo' }

  it { expect(foo).to eq 'foo' }

  context 'with super in subject' do
    subject(:foo) { super().upcase }

    it { expect(foo).to eq('FOO') } # will raise error
  end
end

But why super() in the named subject is much more complex than in the unnamed subject? This is a simplified subject definition you can find in the rspec-core gem:

def self.subject(name = nil, &block)
  if name
    let(name, &block)
    alias_method :subject, name
  else
    let(:subject, &block)
  end
end

So named subject creates two methods. And when you call super() it's become very confusing because it's unclear which method should receive super(). But you can create let with the name matching named subject name. Or if you want to be even more hacky, you can define let(:subject) and call super() there. It will work, but keep in mind that it will modify only one of the two methods. Let me show you this with RSpec example:

RSpec.describe 'named subject' do
  subject(:foo) { 'foo' }

  it { expect(foo).to eq 'foo' }

  context 'with super in let(:foo)' do
    let(:foo) { super().upcase }

    it { expect(foo).to eq('FOO') }
    it { expect(subject).to eq('foo') }
  end

  context 'with super in let(:subject)' do
    let(:subject) { super().upcase }

    it { expect(foo).to eq('foo') }
    it { expect(subject).to eq('FOO') }
  end
end

Summary

Our journey through RSpec's fundamental tools has been truly remarkable! I trust you enjoyed it as much as I did. Let's take a moment to revisit the key points covered in this post:

describe and it are not the only ways to start your example group or examples;
Each describe block is a new class that inherits from the parent describe block;
let is a method;
subject is a let(:subject).

Now that we've got all these new ideas in our heads, let's use them to go on even more exciting testing adventures!

Intro to GraphqlRails

Povilas Jurčys — Wed, 16 Aug 2023 13:50:40 +0000

Introduction

In the ever-evolving landscape of software development, GraphQL has emerged as a powerful tool for crafting flexible and efficient APIs. As Ruby on Rails enthusiasts, we're no strangers to dynamic and elegant nature of Rails applications. Yet, with the rise of GraphQL, new possibilities beckon, challenging us to explore innovative ways of integrating this technology into our Rails projects.

Imagine a world where building robust, secure, and maintainable GraphQL APIs seamlessly aligns with the Rails ecosystem you've come to know and love. Enter GraphqlRails, a gem that transcends the boundaries of conventional development paradigms. It's been three years since the release of GraphqlRails 1.0.0. In that time, it has grown from being a mere extension to the established graphql-ruby library to becoming a transformative framework that redefines GraphQL development within the Rails context.

In this journey of discovery, we'll delve into the unique philosophy of GraphqlRails, one that doesn't just view GraphQL as an isolated entity, but rather, seamlessly intertwines it with the familiar entities of models, controllers, and routes that form the backbone of every Ruby on Rails project. The question that arises naturally is, why opt for GraphqlRails over the well-established graphql-ruby? Strap in as we embark on an exploration of the reasons that make this transition not just worthwhile, but game-changing.

Not just extension for graphql-ruby

In our exploration of GraphqlRails, it's important to grasp that this gem extends far beyond the scope of being a simple extension for graphql-ruby. Initially, GraphqlRails emerged as a compilation of tools geared towards GraphQL-related tasks. Over time, however, it has grown in diverse directions, gradually transforming into a full-fledged framework that stands on its own.

One of the most compelling distinctions that sets GraphqlRails apart from graphql-ruby is its underlying philosophy. In graphql-ruby, GraphQL is treated as a distinct entity with its separate unique ecosystem including it's special directories, types and schemas. On the other hand, GraphqlRails takes a fundamentally different viewpoint. Here, GraphQL is seamlessly integrated into your existing Rails application, harmonizing with the familiar entities of models, controllers, and routes that are ubiquitous in every Ruby on Rails project.

But enough talking. For me, it's always been easier represent my ideas in ruby then in english.

Getting hands dirty

Let's start with graphql-ruby style minimal app:

# app/models/post.rb
class Post < ActiveRecord::Base
  has_many :comments
end

# app/models/comment.rb
class Comment < ActiveRecord::Base
  belongs_to :post
end

# app/graphql/types/post_type.rb
module Types
  class PostType < Types::BaseObject
    field :id, ID, null: false
    field :title, String, null: false
    field :body, String, null: false
    field :comments, [Types::CommentType]
  end
end

# app/graphql/types/comment_type.rb
module Types
  class CommentType < Types::BaseObject
    field :id, ID, null: false
    field :post, PostType, null: false
  end
end

# app/graphql/types/query_type.rb
class QueryType < GraphQL::Schema::Object
  field :post, PostType, "Find a post by ID" do
    argument :id, ID
  end

  # Then provide an implementation:
  def post(id:)
    Post.find(id)
  end
end

# graphql/schema.rb
class Schema < GraphQL::Schema
  query QueryType
end

Now let's write same minimal app in GraphqlRails style:

# app/models/post.rb
class Post < ActiveRecord::Base
  include GraphqlRails::Model

  has_many :comments

  graphql.attribute(:id).type('ID!')
  graphql.attribute(:title).type('String!')
  graphql.attribute(:body).type('String!')
  graphql.attribute(:comments).type('[Comment]')
end

# app/models/comment.rb
class Comment < ActiveRecord::Base
  include GraphqlRails::Model

  belongs_to :post

  graphql.attribute(:id).type('ID!')
  graphql.attribute(:post).type('Post')
end

# app/controllers/graphql/posts_controller.rb
class PostsController < GraphqlRails::Controller
  action(:show).returns('Post')
  def show
    Post.find(id)
  end
end

# graphql/graphql_router.rb
GraphqlRouter = GraphqlRails::Router.draw do
  resources :posts, only: :show
end

As we observe, the end result between the two styles would be almost identical. As projects grow larger, you'll find GraphqlRails becoming more extensible. Just like with Ruby on Rails controllers and models, you'll begin modularizing code through extraction into modules or inheritance. This flexibility is a distinct advantage over the graphql-ruby architecture.

Attaching graphql types to models

At first glance, graphql-ruby's separation of types into distinct classes offers a remarkable degree of flexibility. The concept is simple: return an object with methods matching your GraphQL type or even a hash with keys corresponding to the type's structure. However, this flexibility comes at a significant cost. As types become detached from their models, ensuring robust security, privacy, and system-wide consistency becomes increasingly challenging.

A real-world example from my current workplace, SameSystem, highlights this challenge. We rely on a sophisticated privacy rules with custom permissions for each user, such as emails:read or own_data:read. So for instance, when user is lacking the emails:read permission, API should always return "email": "null". GraphQL's inherent support for deeply nested data demands a careful consideration of permissions at all levels.

To solve this problem, we could wrap our unprotected user with class called ProtectedUser which looks somewhat like this:

To address this issue, we've created a wrapper called ProtectedUser, illustrated below:

class ProtectedUser
  include GraphlqRails::Model

  graphql.name('User')
  graphql.attribute(:email).type('String')

  def initialize(user, viewer)
    @user = user
    @viewer = viewer
  end

  def email
    return nil unless @viewer.permitted?('emails:read', @user)

    @user.email
  end
end

Side note: you are seeing a bit tailored version of policy handling. In practice we use resource_policy gem which handles all the protection logic out of the box. I wrote dedicated article called Protect your GraphQL data with resource_policy on this topic.

GraphqlRails keeps graphql types pure, meaning that they do not change output by their own. The transformation occurs within your model layer.

If your graphql types are not bound to your models, it's very common mistake to return unprotected User instance instead of ProtectedUser and accidentally break the privacy.

When you need to write a controller, there is no hidden magic too:

class Graphql::UsersController < GraphqlRails::Controller
  action(:show).permit(id: 'ID!').returns('ProtectedUser!')
  def show
    user = User.find(params[:id])
    ProtectedUser.new(user, current_user)
  end
end

As you can see, you are expected to return instance of the same type as it was written in the controller's action configuration. This design makes it straightforward to validate output and ensure the controller's action adheres to expectations.

Testing

Testing is my personal obsession. I have done extensive research on graphql-ruby types testing and almost everyone suggests only integration-level specs, rather than unit testing. graphql-ruby itself has a statement about unit it:

By testing these (and other) application-level behaviors without GraphQL, you can reduce the overhead of your test suite and simplify your testing scenarios.

To rephrase it: so you wrote some custom logic in your type and want to make sure it works as expected? Well, you can't!.

Now, here's where GraphqlRails shines. In GraphqlRails, the model and type are essentially one and the same. When you test the model, you inherently test the type. Unlike graphql-ruby, GraphqlRails style types does not have any hidden logic that you should be worried about. Let's break down how you can conduct unit testing for your graphql type/model:

describe ProtectedUser do
  let(:protected_user) { described_class.new(user, viewer) }
  let(:user) { create(:user) }
  let(:viewer) { create(:user) }

  describe '#email' do
    subject(:email) { protected_user.email }

    context 'without "emails:read" permission' do
      it { is_expected.to be_nil }
    end

    context 'with "emails:read" permission' do
      before { viewer.add_permission('emails:read', user) }
      it { is_expected.to eq(user.email) }
    end
  end
end

With our type thoroughly tested, we can move on to creating straightforward controller tests to ensure our outputs align with expectations:

describe Graphql::UsersController, graphql_controller: true do
  describe '#show' do
    let(:request) do 
      query(:show, params: params, graphql_context: gql_context)
    end
    let(:params) { { id: user.id } }
    let(:gql_context) { { viewer: viewer } }
    let(:user) { create(:user) }
    let(:viewer) { create(:user) }   

    it 'returns ProtectedUser' do
      expect(request.result).to be_a(ProtectedUser)
    end 
  end
end

This approach effectively lifts the veil off GraphQL as a black box, enabling testing beyond integration scenarios. GraphqlRails provides a familiar controller-model interplay that can be tested step by step using unit testing techniques.

Decorators

In various scenarios, you might not want to blend your GraphQL type definitions directly into your Ruby on Rails models. You might want slightly different logic for your GraphQL responses. This is where GraphqlRails::Decorator comes to the rescue. Under the hood, it functions same as GraphqlRails::Model, but it's better suited for situations involving paginated responses. What makes it particularly useful is the introduction of the .decorate method, which simplifies the process of decorating a collection.

Let's illustrate the significance of GraphqlRails decorators by creating a paginated users controller's index action:

Let's begin by examining the index action without using a decorator:

class Graphql::UsersController < GraphqlApplicationController
  action(:index).paginated.returns('[ProtectedUser!]!')
  def index
    User.all.map do |user| 
      ProtectedUser.new(usr, current_user)
    end
  end
end

Both graphql-ruby and GraphqlRails supports pagination out of the box. You do not need to think on how to split your collection into smaller batches in order to show limited amount of data (by default it's a 200 items per page). However, there's a catch - pagination works efficiently with ActiveRecord records only.

In the provided index example, I demonstrated a somewhat inefficient approach without using GraphqlRails::Decorated. The inefficiency stems from loading all users from the database and then constructing ProtectedUser instances for each user. Yet, for pagination, we only require a subset of users, not the entire collection. If you have a million users, this inefficiency becomes a significant problem. The simplest way to solve this is by turning ProtectedUser into a decorator. This is easily accomplished by replacing GraphqlRails::Model with GraphqlRails::Decorator:

class ProtectedUser
  include GraphlqRails::Decorator

  graphql.name('User')
  graphql.attribute(:email).type('String')

  def initialize(user, viewer)
    @user = user
    @viewer = viewer
  end

  def email
    return nil unless @viewer.permitted?('emails:read', @user)

    @user.email
  end
end

With just one line replaced in our type class, we can update our controller and return decorated records:

class Graphql::UsersController < GraphqlApplicationController
  action(:index).paginated.returns('[ProtectedUser!]!')
  def index
    ProtectedUser.decorate(User.all, current_user)
  end
end

The .decorate method takes a list or query as its first argument, and any subsequent arguments are shared across all decorated items. This method emulates the behavior of an ActiveRecord query, ensuring it fetches only the necessary records for the specific page.

Rendering errors

In the realm of Rails, encountering errors is an everyday occurrence. Sometimes, things don't go as planned and the system crashes. In these situations, GraphqlRails comes to the rescue by automatically rendering system errors. However, there are situations when you'd like to take charge of error rendering manually, without causing the system to crash. This is where the render method within the controller comes into play:

action(:create)
  .permit_input(:input, type: 'User')
  .returns('User!')

def create
  new_user = User.new(params[:input])
  if current_user.forbidden_to?(:create, new_user)
    return render(errors: ['Create is forbidden'])
  end

  return new_user if new_user.save

  render(errors: new_user.errors)
end

Notice the straightforward error handling within this controller action. If you take a closer look, you will notice, that we render different type of errors in different places.

In this part we render stings as errors:

return render(errors: ['Create is forbidden'])

And in this part we render validation errors:

render(errors: new_user.errors)

It's not a coincidence that this gem has Rails word in it.

Final Thoughts

Our journey through the world of GraphqlRails has been a revelation. From its inception as an extension to graphql-ruby to its transformation into a full-fledged framework, GraphqlRails has evolved into a valuable asset for developers seeking a streamlined, consistent, and secure approach to GraphQL development within Ruby on Rails applications.

Embracing GraphqlRails isn't just a matter of adopting a gem; it's about embracing a philosophy that melds GraphQL seamlessly into the Rails ecosystem. This unique integration philosophy bridges the gap between familiar Rails constructs and the dynamic world of GraphQL. By doing so, GraphqlRails redefines how we approach building APIs that are robust, secure, and maintainable.

The power of GraphqlRails lies in its ability to unify models and types, simplifying the management of permissions, privacy, and consistency. By treating GraphQL types as extensions of models, the gem not only preserves Rails conventions but also enhances the security of your application. This streamlined approach not only simplifies development but also fosters confidence in the security of your data.

Moreover, GraphqlRails introduces a paradigm shift in testing. Unlike traditional GraphQL testing, which often leans heavily on integration tests, GraphqlRails empowers developers to conduct unit testing on GraphQL types/models. This approach aligns testing practices with the principles of object-oriented programming and promotes encapsulation, making your application's behavior more comprehensible and testable.

As we conclude our journey, let's not just view GraphqlRails as a technical tool but as an enabler of innovation. It redefines how we craft GraphQL APIs, offering an alternative path that harmonizes GraphQL with Ruby on Rails. Whether you're starting a new project or considering a transition, the insights gained from GraphqlRails can pave the way for more efficient, secure, and maintainable GraphQL development.

Many ways to write RSpec custom matchers

Povilas Jurčys — Mon, 31 Jul 2023 10:06:59 +0000

Introduction

RSpec matchers are the backbone of effective testing, enabling developers to make precise assertions about their code's behavior and validate specific conditions. While RSpec comes equipped with a useful set of built-in matchers like eq, be, and include, there are instances where these might not fully capture the nuances of the behavior you want to test. This is where custom matchers come into play, providing you with the ability to define your own matchers tailored to your application's domain and unique requirements.

Two Approaches

When it comes to creating custom matchers in RSpec, developers have two powerful approaches at their disposal. Each method offers distinct advantages, giving you the flexibility to tailor your matchers to your specific testing needs. In this article, we will delve into both of these approaches to equip you with the knowledge to write expressive and adaptable tests.

Creating Matchers through RSpec DSL:

The RSpec DSL (Domain-Specific Language) provides a concise and straightforward way to define custom matchers for simpler use cases. It abstracts away much of the implementation complexity, allowing you to focus on the core logic of your matchers.

While the RSpec DSL provides simplicity and conciseness, it may become less manageable and harder to test as the complexity of your custom matchers grows.
Creating Matchers as Ruby Classes:

For more complex matchers with advanced logic, defining matchers as Ruby classes offers greater flexibility and maintainability. By creating a custom Ruby class, you can organize the matcher's code better, test it independently, and reuse it across different test suites.

Defining a custom matcher as a class involves creating a new Ruby class with the necessary methods for matching logic. This approach allows you to write comprehensive tests for your custom matchers and ensures better code organization and reusability.

In this article, we will explore both of these methods in detail, illustrating how to create custom matchers using the RSpec DSL and defining matchers as Ruby classes. By understanding the strengths of each approach, you can leverage the power of custom matchers to write expressive and adaptable tests, resulting in more robust and maintainable test suites.

Creating matcher with `alias_matcher`

Let's start by exploring the simplest custom matcher that we can create using RSpec's DSL. One particularly useful built-in matcher is contain_exactly, but it might feel a bit too verbose at times. With the RSpec::Matchers.alias_matcher method, we can craft shorter aliases for existing matchers:

RSpec::Matchers.alias_matcher :contain, :contain_exactly

Now, we can use both the original and the shortened form interchangeably:

expect(%w[a b c]).to contain('c', 'b', 'a')
expect(%w[a b c]).to contain_exactly('c', 'b', 'a')

RSpec has already a lot aliases for its build-in methods (list could be found here), so prefer using alias_matcher for your own custom matchers instead.

Creating matcher `define_negated_matcher`

Another one-liner that allows to create custom matcher is RSpec is the RSpec::Matchers.define_negated_matcher, a powerful tool that simplifies your test code by creating negated versions of existing matchers.

I find one particular negated matcher so handy that I always add it in every Ruby on Rails project I create. It's a negative matcher for changed. Without negated matcher, you can't check if some changes occur and some changes did not in a single spec.

Let's start with the example that does not use nagated matcher:

it 'updates user first_name' do
  expect { UpdateUser.call(user, first_name: 'John') }
    .to change(user, :first_name)
end

it 'does not update user last_name' do
  expect { UpdateUser.call(user, first_name: 'John') }
    .and keep_unchanged(user, :last_name)
end

Let's create negated matcher using RSpec DSL:

RSpec::Matchers.define_negated_matcher :keep_unchanged, :change

With this negative matcher, you can now write previous specs as one single assertion:

it 'updates user first_name only' do
  expect { UpdateUser.call(user, first_name: 'John') }
    .to change(user, :first_name)
    .and keep_unchanged(user, :last_name)
end

Negated matchers allows you to express negative expectations without duplicating code or sacrificing readability, resulting in a more organized, maintainable, and comprehensible test suite.

Creating matcher with `matcher`

For scenarios where the built-in matchers aren't sufficient, we can create more complex matchers using the RSpec::Matchers.matcher method.

Let's create a custom matcher that checks whether a given string is a URL:

# uri_host_matcher.rb
RSpec::Matchers.matcher :be_url do
  match do |actual|
    actual.to_s =~ URI.regexp
  end
end

This matcher uses the match block to define the logic for determining whether the given string is a properly formatted URL. Now, let's write tests to ensure its functionality:

expect('https://example.com').to be_url
expect('https://dev.to/povilasjurcys').to be_url
expect('Hello!').not_to be_url

By creating matchers with matcher, we gain the ability to define custom assertions and validations that go beyond the built-in RSpec matchers, providing greater flexibility and expressiveness in our test suites.

Describing the matcher Result

When using custom matchers in RSpec, it's essential to have clear and informative descriptions for both successful and failed expectations. This helps in understanding the purpose and intent of the custom matcher, making test failures easier to interpret.

By default, RSpec generates description and failure messages based on the matcher name, which is suitable for simple cases. However, as matchers become more complex, it becomes beneficial to customize the descriptions to improve clarity.

Customizing Description

To provide a custom description for the matcher, we can use the description helper within the custom matcher block. Let's take our be_url custom matcher as an example:

# uri_host_matcher.rb
RSpec::Matchers.define :be_url do
  description { 'be a URL' }

  match do |actual|
    actual.to_s =~ URI.regexp
  end
end

By adding the description block, we override the default description for our be_url matcher. Now, when we use this matcher in our specs, the description becomes better formatted:

it { is_expected.to be_url }

The failure message will also reflect the updated description:

CustomMatchers is expected to be a URL

Customizing Failure Messages

Customizing failure messages is especially useful when debugging failing specs. It allows us to provide more context and details about the failure, making it easier to identify the problem.

In our be_url custom matcher, we can add failure_message and failure_message_when_negated blocks to adjust the failure messages for positive and negative expectations, respectively:

# uri_host_matcher.rb
RSpec::Matchers.define :be_url do
  description { 'be a URL' }
  failure_message { "'#{actual}' does not look like a URL" }
  failure_message_when_negated { "'#{actual}' is a URL" }

  match do |actual|
    actual.to_s =~ URI.regexp
  end
end

Now, when a spec fails, we get more informative failure messages:

CustomMatchers is expected to be a URL
  Failure/Error: it { is_expected.to be_url }
    'foo' does not look like a URL

CustomMatchers is expected not to be a URL
  Failure/Error: it { is_expected.not_to be_url }
    'http://dev.to' is not a URL

With customized failure messages, it becomes easier to pinpoint the issue when a spec fails, leading to faster troubleshooting and resolution.

Customizing the descriptions and failure messages of custom matchers enhances the clarity and readability of our test suites. It allows us to communicate the purpose and intent of the matchers effectively, even in more complex scenarios. With these customization options, we can make our RSpec test suites more expressive and developer-friendly.

Custom Matchers with Arguments

In many testing scenarios, we encounter situations where custom matchers need to accept arguments to perform more specific comparisons. RSpec allows us to create custom matchers that can take arguments for more fine-grained control over the matching process.

Let's explore how to create a custom matcher with arguments by taking the example of a have_host matcher that checks if a given URL-like string contains an expected host:

# uri_host_matcher.rb
RSpec::Matchers.define :have_host do |expected|
  match do |actual|
    URI.parse(actual).host == expected
  end
end

In this example, we define the have_host matcher with an argument named expected. The expected value represents the host we want to check for in the URL-like string.

We can now use this custom matcher with arguments in our tests like this:

expect('https://dev.to/povilasjurcys').to have_host('dev.to')
expect('https://example.com').to have_host('example.com')

By defining custom matchers with arguments, we can make our matchers more flexible and reusable. They can be adapted to various scenarios by providing different values as arguments, allowing us to perform specific and precise assertions in our tests.

Additionally, combining arguments with other RSpec matchers or chaining them together further enhances the expressive power of our custom matchers. With this capability, we can create highly tailored and focused assertions for different aspects of our application's behavior.

Chaining custom matchers

In RSpec, custom matchers can be made chainable, enabling us to create more expressive and concise assertions by combining multiple matchers together. Chaining custom matchers allows for complex and fine-grained validations while maintaining readability in our test code.

Let's see how we can make our be_url custom matcher chainable with an additional matcher called with_host to check if a given URL-like string contains the expected host:

# uri_host_matcher.rb
RSpec::Matchers.define :be_url do
  chain :with_host do |host|
    @host = host
  end

  match do |actual|
    actual =~ URI.regexp && 
      (@host.nil? || URI.parse(actual).host == @host)
  end
end

In this example, we define a chainable with_host method within our be_url custom matcher. The with_host method takes an argument host, representing the expected host to check in the URL-like string.

Now, we can use the custom matcher with chaining in our tests like this:

expect('https://dev.to/povilasjurcys')
  .to be_url.with_host('dev.to')

By chaining custom matchers together, we create more expressive and focused assertions that provide specific and detailed validation of our application's behavior. This approach enhances readability and helps us build comprehensive test cases that cover various aspects of our code's functionality.

Chaining custom matchers is a powerful technique that allows us to create versatile and efficient test suites, making our tests more maintainable and easier to understand.

Embracing Ruby Class Matchers: When and Why to Use Them

When it comes to creating custom matchers in RSpec, developers often face a crucial decision: whether to use the RSpec DSL or opt for defining matchers as Ruby classes. While the RSpec DSL offers a quick and concise solution for straightforward cases, there are compelling reasons to consider using Ruby class matchers for more complex scenarios. Let's explore when and why developers should embrace Ruby class matchers:

Handling complex logic:
Ruby class matchers are ideal for situations where custom matchers require intricate logic and multiple conditions. As the matcher's complexity grows, using Ruby classes allows for more organized and maintainable code, with private methods to break down the logic into manageable pieces.
Enhanced testability:
Writing tests for custom matchers is essential to ensure their correctness and robustness. Ruby class matchers offer better testability, as each component of the matcher can be tested independently. This isolation makes debugging and troubleshooting much easier when issues arise.
Modularity and reusability:
Ruby classes can be easily shared and reused across different test suites. With includes or inheritance, you can create a library of reusable methods that can be utilized in multiple custom matchers, promoting code modularity and reducing duplication.
Combining matchers:
When dealing with complex expectations that involve chaining multiple matchers together, Ruby class matchers provide a more straightforward approach. The ability to chain matchers together allows developers to create expressive and focused assertions that cover various aspects of their application's behavior.

Creating a Ruby Class Matcher

Defining custom matchers as Ruby classes offers developers a robust and flexible approach to creating expressive and testable matchers. By encapsulating the matching logic within a class, developers gain better control over their custom matchers, leading to more organized and maintainable code.

To define a custom matcher as a Ruby class, follow these steps:

Create the ruby class:
Begin by creating a new class for your custom matcher. Include a matches? method within the class, which will contain the actual matching logic.
Add descriptive messages (Optional):
Optionally, you can add description, failure_message, and failure_message_when_negated methods to provide descriptive messages when the matcher fails. These messages enhance the readability of your test output and aid in debugging.

Here's an example of a ruby class matcher, demonstrating the BeUrl class:

# spec/support/custom_matchers/be_url.rb
class BeUrl
  def description
    'be a URL'
  end

  def matches?(actual)
    @actual = actual

    url? && matches_host?
  end

  def with_host(host)
    @host = host
  end

  private

  def url?
    @actual =~ URI.regexp
  end

  def matches_host?
    @host.nil? || URI.parse(@actual).host == @host
  end
end

Using the Ruby Class Matcher

To use the BeUrl custom matcher, create a helper method that instantiates the class:

# in the bottom of spec/support/custom_matchers/be_url.rb:
def be_url
  BeUrl.new
end

Now, you can call the custom matcher in your tests, just like before:

expect('https://dev.to/povilasjurcys')
  .to be_url.with_host('dev.to')

Optimal Long-Term Solution

Although Ruby class matchers may require writing a bit more code initially, the benefits they provide in the long run make them a recommended choice for handling complex testing scenarios. The increased testability, maintainability, and reusability offered by Ruby class matchers empower developers to build more comprehensive and reliable test suites.

Conclusion

Custom RSpec matchers are a powerful tool that empowers developers to write more expressive and precise tests. While RSpec provides a solid set of built-in matchers, there are scenarios where custom matchers are necessary to tackle specific testing requirements.

By delving into two approaches for creating custom matchers —using the RSpec DSL and defining matchers as Ruby classes — we've explored the flexibility and advantages of each method. The RSpec DSL offers concise and quick solutions for simpler cases, while Ruby classes provide scalability, maintainability, and testability for more complex scenarios.

Mastering the art of custom matchers allows developers to enhance their test suites, resulting in more reliable and comprehensible code. So, don't hesitate to experiment and discover the best matchers that suit your testing needs. Embrace the power of custom matchers to unlock the full potential of RSpec and elevate your testing game! Happy testing!

Deep Dive into RSpec's let Helper

Povilas Jurčys — Thu, 13 Jul 2023 04:19:03 +0000

Introduction

RSpec provides developers with a wide array of tools to write effective and robust tests. Among its many powerful features, the let helper quietly stands as a versatile tool for creating reusable variables within test examples.

The let helper allows developers to define variables within test examples, memoizing their values for efficient reuse. While let may not appear as attention-grabbing as other RSpec features, its clever usage can significantly improve test readability, maintainability, and execution speed.

In this article, we will dig deep to explore the potential of the let helper and it's friendly neighbors let! and subject. We will unravel its capabilities for creating reusable variables and optimizing a test code.

Understanding `let` Blocks in RSpec

Before delving into more depth techniques, let's talk about the nature of let block and why it's so useful. let block has 3 features which makes it a great tool:

let can be redefined

In RSpec, the let keyword allows you to define variables that can be redefined within nested contexts. This means that you can override the initial definition of a let variable within a more specific context, providing flexibility in setting different values for the same variable in different scenarios.
let is memoized

let block value is computed only once and then cached for subsequent references within the same example or context. This memoization ensures that the value of a let variable remains consistent throughout the example or context, even if it is referenced multiple times.
let is lazy evaluated

let block value is not computed until the first time it is accessed within a specific example or context. This lazy evaluation improves performance by avoiding unnecessary computations for let variables that might not be used in a particular test scenario.

Using `super()` within `let` blocks

The super() keyword in Ruby is typically used to call a method of the same name in the superclass. In the context of RSpec's let blocks, super() enables us to inherit and extend values defined in the parent context, providing a powerful mechanism for code reuse.

Let's consider an example where we have a ShoppingCartItem class and want to test its pricing functionality. The code snippet below demonstrates how we can utilize super() within let blocks to achieve this:

RSpec.describe ShoppingCartItem do
  subject(:item) { described_class.new(item_params) }
  let(:item_params) { { name: 'Item', price: 10 } }

  it 'returns a full price' do
    expect(item.price).to eq(10)
  end

  context 'with a discount' do
    let(:item_params) { super().merge(discount: 2) }

    it 'returns a discounted price' do
      expect(item.price).to eq(8)
    end
  end
end

In this scenario, we have a ShoppingCartItem spec with a subject, item, representing an instance of ShoppingCartItem initialized with item_params. The item_params let block defines the default parameters for the item, including the name and price.

Within the nested context, 'with a discount', we redefine item_params using super(), which inherits and extends the original item_params from the parent context. By merging a discount key with a value of 2, we modify the parameters to include a discount.

The subsequent test case within the nested context verifies that the item's price, accessed through item.price, correctly reflects the discounted price of 8.

Benefits of super() in let blocks:

Code Reusability. By leveraging super() in let blocks, we can avoid duplicating variable definitions in nested contexts. Instead, we inherit and extend variables from parent contexts, promoting code reuse and reducing redundancy.
Flexibility and Dynamism. super() enables us to dynamically modify variables based on specific contexts or scenarios. This flexibility allows us to create adaptable tests that can handle varying scenarios without the need for redundant code.
Maintainability. Using super() within let blocks improves the maintainability of tests by centralizing variable definitions in parent contexts. Modifying the inherited variable in a single location ensures consistency and reduces the likelihood of errors caused by inconsistent values.

Understanding the impact of `super()` in the `subject`

At first glance, using super() in subject seems straightforward, but what if we introduce named subjects? Let's explore the behavior when you define a named subject, such as subject(:value) { 'foo' }, and then call let(:value) { super() } within a nested context. If this scenario leaves you unsure, read on as we delve into the complexities.

To better understand the implications of combining these helpers, I conducted several experiments with super() in different scenarios. Here's a handy cheat-sheet presented in RSpec code:

describe "super() in `subject` or `let` blocks" do
  subject(:value) { 'subject(:value)' }

  context 'with `super()` in `let` with subjects name' do
    let(:value) { "#{super()} + let(:value)" }

    it 'appends `let` content to named variable' do
      expect(value).to eq('subject(:value) + let(:value)')
    end

    it 'keeps subject unchanged' do
      expect(subject).to eq('subject(:value)')
    end
  end

  context 'with `super()` in named subject' do
    subject(:value) { "#{super()} same" }

    it 'does not allow calling super in named subject' do
      expect { subject }.to raise_error(
        '`super` in named subjects is not supported'
      )
    end
  end

  context 'when calling `super()` in unnamed subject' do
    subject { "#{super()} + subject" }

    it 'appends content to previously defined subject' do
      expect(subject).to eq('subject(:value) + subject')
    end

    it 'keeps named variable unchanged' do
      expect(value).to eq('subject(:value)')
    end
  end

  context 'with `super()` in unnamed subject and `let`' do
    subject { "#{super()} + subject" }
    let(:value) { "#{super()} + let(:value)" }

    it 'joins previous and current `subject` contents' do
      expect(subject).to eq('subject(:value) + subject')
    end

    it 'joins same-name subject and `let` contents' do
      expect(value).to eq('subject(:value) + let(:value)')
    end
  end
end

Although knowing the outcome of these tests is informative, it's crucial to note that this scenario is not a common one. In practice, I strongly advise against using super() in the subject whenever possible. Remember, the subject should serve as a starting point for each specification, and calling super() within it might violate this principle.

Now, let's shift our focus to exploring the mechanics of the let! helper and uncover the do's and don'ts in this area.

`let!` - the non-lazy alternative

The let! construct serves as a non-lazy version of let in RSpec. Unlike let, let! is invoked before the corresponding it block. This feature proves useful when you need to set up external records before invoking the subject. Consider the following example:

class User < ActiveRecord::Base
  def same_name_users
    User.where(name: name)
  end
end

describe User do
  subject(:user) { User.new(name: 'John') }

  describe '#same_name_users' do
    subject(:same_name_users) { user.same_name_users }

    let!(:another_john) { User.create!(name: 'John') }

    it 'returns users with same name' do
      expect(same_name_users).to eq([another_john])
    end
  end
end

If we were to replace let! with let in this example, the test would fail. Without let!, the same_name_users variable would be called and memoized before another_john is invoked. As a result, the same_name_users would return an empty list.

By using let!, we ensure that another_john is created and called before the invocation of same_name_users, ultimately leading to a passing test. However, an important question arises: when exactly are let! variables invoked?

When exactly are `let!` variables invoked?

As always, things are easy as long as they are simple, but let's see what will happen after mixing around and before hooks.

To better understand the implications of combining these helpers, I conducted several experiments with super() in different scenarios. Here's another handy cheat-sheet presented in RSpec code:

describe 'using `let!` with other hooks' do
  def log_call(name)
    @call_log ||= []
    @call_log += [name]
  end

  context 'when let! is defined before other hooks' do
    let!(:value) { log_call('let!') }
    around { |example| log_call('around'); example.run }
    before { log_call('before') }

    it 'runs let! between `around` and `before` hooks' do
      expect(@call_log).to eq(%w[around let! before])
    end
  end

  context 'when let! is defined after other hooks' do
    around { |example| log_call('around'); example.run }
    before { log_call('before') }
    let!(:value) { log_call('let!') }

    it 'runs let! after other hooks' do
      expect(@call_log).to eq(%w[around before let!])
    end
  end

  context 'when `let!` goes first in parent context' do
    let!(:value) { log_call('let!') }
    around { |example| log_call('around'); example.run }
    before { log_call('before') }

    context 'when redefining let! in nested context' do
      let!(:value) { log_call('nested-let!') }

      it 'runs let! between `around`` and `before` blocks' do
        expect(@call_log)
          .to eq(%w[around nested-let! before])
      end
    end
  end

  context 'when `let!` goes last in parent context' do
    around { |example| log_call('around'); example.run }
    before { log_call('before') }
    let!(:value) { log_call('let!') }

    context 'when redefining let! in nested context' do
      let!(:value) { log_call('nested-let!') }

      it 'runs let! after `around`` and `before` blocks' do
        expect(@call_log)
          .to eq(%w[around before nested-let!])
      end
    end
  end
end

Based on the outcomes, it becomes evident that let! is essentially equivalent to:

let(:value) { "something" }
before { value }

There are situations where you might want your let! variable to execute before the before block, while in other cases, you may prefer it to execute after the before block. However, keep in mind that such an approach can lead to inconsistencies in your spec structure. Here's a simplified example of code that works but is not considered good practice:

let!(:do_it_first) { puts "first" }
before { puts "second" }
let!(:do_it_third) { puts "third" }
before { puts "forth" }

Introducing let! adds another layer to the already complex flow of RSpec hooks. It is generally better to maintain simplicity and readability in your specs by using a combination of let and before hooks instead of relying heavily on let!. Consider the following alternative approach:

let(:do_it_first) { puts "first" }
let(:do_it_third) { puts "third" }

before do 
  do_it_first
  puts "second"
  do_it_third
  puts "forth"
end

By adopting this approach, you can keep your codebase clean, easy to follow, and less prone to potential inconsistencies.

Conclusion

In this article, we delved into the power of RSpec's let helper and explored its friendly companions, let! and subject. let offers three key features: redefinability, memoization, and lazy evaluation. By leveraging let blocks, developers can enhance test readability, maintainability, and execution speed.

We also explored the usage of super() within let blocks, which allows us to inherit and extend values defined in the parent context. However, using super() in the subject is not recommended, as it can violate the principle of the subject serving as a starting point for each specification.

Additionally, we investigated the behavior of let!, which acts as a non-lazy version of let. let! is useful for setting up external records before invoking the subject, ensuring the proper setup for certain test scenarios. Nevertheless, use of let! can complicate the flow of RSpec hooks and lead to inconsistencies in the test structure.

Overall, the article provided a deeper knowledge and insights into the advanced usage of let in RSpec. It highlighted the benefits of using super() for code reusability, flexibility, and maintainability. By understanding the capabilities of let and considering its usage in conjunction with super(), developers can optimize their tests and create robust and efficient test suites.

Protect your GraphQL data with resource_policy

Povilas Jurčys — Mon, 20 Feb 2023 04:41:46 +0000

GraphQL is a query language for APIs that was created by Facebook. It provides a more efficient, powerful, and flexible alternative to REST APIs. One of the main advantages of GraphQL is that it allows clients to request exactly the data they need, and nothing more.

In addition to its flexibility, GraphQL also provides an excellent way to handle authorization and access control. Authorization is the process of ensuring that a user has the proper permissions to perform an action, and access control refers to the methods and policies that regulate which users can access specific resources or data.

In this article, we will discuss how to integrate GraphQL with resource_policy, a Ruby gem for attribute-level authorization, to create fine-grained access control for your API. We will cover the basic concepts of resource_policy, how to use it to protect your resources, and how to expose your policies through GraphQL to provide your API users with visibility into which data they can access.

Two layers of protection

If you are interested in the authorization levels concept, I recommend checking my previous article titled Attribute level permission control in Rails where I delved into the topic of authorization and its two layers - action and attribute. In this article, I will focus on the implementation.

In simple terms, action authorization is a straightforward approach where a user's request is either accepted or rejected based on their role or other conditions. This approach is implemented in a controller through a simplified code such as:

class UsersController < ApplicationController
  before_action :require_admin, only: [:create]

  def show # everyone can do this action
    # ...
  end

  def create # only admins can do this action
    # ...
  end
end

However, in attribute-level authorization, the system does not reject the request but rather returns only part of the requested data. For instance, different response bodies may be returned based on the user making the request.

// user(id: 1) response for admin
{
  "data": {
    "id": 1
    "email": "john@example.com"
  }
}

// user(id: 1) response for non-admin
{
  "data": {
    "id": 1
    "email": null // email is not authorized to see
  }
}

Attribute-level authorization is more complex, but it is essential in more intricate applications. Luckily, there are tools like the resource_policy gem that make it easier to achieve this type of authorization.

What is resource_policy?

If you're looking for an easy way to configure attribute-level authorization for your Rails application, look no further than resource_policy. Based on the PolicyObject pattern, this gem offers several methods to make configuration simple.

In a PolicyObject class, for example, you can use the policy method to specify which attributes are allowed for which actions. In the following example, the id attribute can be read, and the email attribute can be read only if the current user is an admin:

class UserPolicy
  include ResourcePolicy::Policy

  policy do |c|
    c.attribute(:id).allowed(:read)
    c.attribute(:email).allowed(:read, if: :admin?)
  end

  def initialize(user, current_user)
    @user = user
    @current_user = current_user
  end

  def admin?
    @current_user.admin?
  end
end

One of the benefits of resource_policy is that it's easy to integrate with other gems like a pundit, so you don't have to rewrite everything. If you're looking for a straightforward way to implement attribute-level authorization, resource_policy is definitely worth considering.

resource_policy and GraphQL

If you're using GraphQL and want to protect your data with a simple configuration, resource_policy provides a method called protected_resource. This method wraps your record and returns nil for every unauthorized attribute, making it easy to protect your data with a few lines of code.

For example, consider the following code:

current_user.admin? #=> false

user = User.find(1337)
user.id #=> 1337
user.email #=> "john.doe@example.com"

policy = UserPolicy.new(user, current_user)
protected_user = policy.protected_resource
protected_user.id #=> 1337
protected_user.email # nil

In this example, protected_resource returns a user record with only the authorized attributes, which is useful for protecting data in GraphQL. With a few lines of code, you can configure resource_policy to protect your data in GraphQL:

class Types::QueryType < GraphQL::Schema::Object
  field :users, [UserType], 'Returns protected users'

  def users
    current_user = context[:current_user]
    Users.all.map do |user|
      UserPolicy.new(user, current_user).protected_resource
    end
  end
end

By using UserPolicy.new(user, current_user).protected_resource, you can wrap the user record with the policy and return only the authorized attributes to the client. This makes it easy to add attribute-level authorization to your GraphQL API with minimal effort.

Querying policies itself

Expressing authorization rules can be a bit challenging with the use of other authorization gems, such as pundit or cancancan. The resource_policy gem provides a more concise and expressive policy definition that uses a simple block-based syntax that makes it easy to understand and write authorization rules for each attribute.

One of the benefits of resource_policy is that you have easy access to the protected attributes list through user_policy.attributes_policy.all_allowed_to(:read). This feature provides fine-grained control over attribute access by specifying different access levels, such as :read or :write.

With these features, resource_policy is a great option if you want to expose policies through GraphQL or an API. Exposing policies is important because it helps the frontend or any other heavy GraphQL user know which data they can access before making any real request. To give an idea, GraphQL can look like the following query:

query userPolicy(id: 123) {
  email {
    isReadable
    isWritable
  }

  name {
    isReadable
    isWritable
  }
}

This query returns something like the following, based on the policy result:

{
  "data": {
    "userPolicy" {
      "user" {
        "email": {
          "isReadable": true
          "isWritable": false
        },
        "name": {
          "isReadable": true
          "isWritable": true
        }
      }
    }
  }
}

This way, the GraphQL user can decide whether to render input fields that are read-only or skip making requests altogether.

Implementation details

You might be wondering how to implement resource_policy with GraphQL. While the library does not come with built-in GraphQL support, it can be easily integrated with GraphQL using a few lines of code.

To get started, you'll need to create an AttributePolicyType that exposes the access levels for each attribute. In the simplest case, you might expose only read and write levels:

class AttributePolicyType < GraphQL::Schema::Object
  field :is_writable, GraphQL::Types::Boolean, property: :writable?
  field :is_readable, GraphQL::Types::Boolean, property: :readable?
end

You'll also need to create a policy type for each model. For example, you can create a UserPolicyType to expose the data from the UserPolicy:

class UserPolicyType
  UserPolicy.policy.attributes.each_key do |attribute|
    field attribute, AttributePolicyType
  end  
end

This class defines attributes dynamically based on the policy, so you don't need to hard-code them.

Finally, you can update the Query type to make the policy accessible via GraphQL:

class Query < GraphQL::Schema::Object
  # ...
  field :user_policy, UserPolicyType do
    argument :id, ID
  end

  def user_policy(id:)
    user = User.find(id)
    UserPolicy.new(user, context[:current_user])
  end
end

Now you can query the policy using query userPolicy(id: 1) { ... } to find out which attributes are accessible. This can be useful for front-end developers who want to know which data they can access before making any requests.

Final thoughts

In conclusion, resource_policy is a powerful and flexible gem that can help you easily implement attribute-level authorization in your Ruby on Rails application. Its concise and expressive policy definition, easy access to protected attributes, and fine-grained control over attribute access make it a strong contender for exposing policies via GraphQL or API.

By following the steps outlined in this article, you can create an AttributePolicyType and UserPolicyType, and update your Query GraphQL type to expose your policies. This will enable your GraphQL users to know which data they have access to before making any real requests, thus helping them make better decisions and reduce unnecessary network traffic.

While resource_policy does not have out-of-the-box GraphQL support, it can be easily integrated with GraphQL with just a few lines of code. With resource_policy, you can ensure that your application's data is protected and accessible only by authorized users, providing a more secure and reliable user experience.

Attribute level permission control in Rails

Povilas Jurčys — Fri, 10 Feb 2023 11:13:22 +0000

Authorization in API can be a complex task for developers as it requires a thorough understanding of security and access controls. Authorization is the process of granting or denying access to specific resources, actions, or data based on the user's permissions or roles. In a Ruby on Rails API, authorization can be implemented at the controller level, action level, or attribute level.

No authorization

To understand the complexity of authorization, let's start with a simple Ruby on Rails API controller example that does not have any authorization.

# app/controllers/api/v1/posts_controller.rb

class API::V1::PostsController < ApplicationController
  def create
    @post = Post.new(post_params)
    @post.save!
    render json: serialized(@post)
  end

  def update
    @post = Post.find(params[:id])
    @post.update!(post_params)
    render json: serialized(@post)
  end

  def show
    @post = Post.find(params[:id])
    render json: serialized(@post)
  end

  private

  def serialize(post)
    # custom serialization logic
  end
end

In this example, anyone can create, update, or show posts. However, in most applications, only certain users should have access to certain resources or actions.

Action-level authorization

To implement action-level authorization, we can use the before_action method in the controller.

# app/controllers/api/v1/posts_controller.rb

class API::V1::PostsController < ApplicationController
  before_action :authenticate_user!
  before_action :authorize_user!, only: [:create, :update]

  def create
    @post = Post.new(post_params)
    @post.save!
    render json: serialized(@post)
  end

  def update
    @post = Post.find(params[:id])
    @post.update!(post_params)
    render json: serialized(@post)
  end

  def show
    @post = Post.find(params[:id])
    render json: serialized(@post)
  end

  private

  def authorize_user!
    if current_user.role == 'author'
      flash[:error] = "You can't access this page."
      redirect_to root_path
    end
  end

  def serialize(post)
    # custom serialization logic
  end
end

In this example, the authenticate_user! method ensures that only logged-in users can access the API. The authorize_user! method checks if the current user has the author role, and if not, redirects the user to the root path.

While this implementation of action-level authorization works, it is limited in terms of granularity.

Attribute-level authorization

In most applications, authorization needs to be applied not only to actions but also to methods, attributes, and resources. To simplify attribute-level authorization, we can use the resource_policy gem.

The resource_policy is a policy-based authorization gem for Ruby applications. It provides a simple and flexible way to manage authorization at the action, attribute, and resource level.

The policy class looks like this::

# app/policies/post_policy.rb

class PostPolicy
  include ResourcePolicy::Policy

  policy do |c|
    c.action(:create).allowed(if: :editor?)
    c.action(:update).allowed(if: :author?)
    c.action(:show).allowed

    c.attribute(:id).allowed(:read)
    c.attribute(:body).allowed(:read).allowed(:write, if: :author?)
    c.attribute(:author_phone).allowed(:read, if: :admin?)
  end

  delegate :admin?, :editor?, to: :@current_user

  def initialize(post, current_user)
    @post = post
    @current_user
  end

  def author?
    @post.author == current_user
  end
end

The PostPolicy is a policy class used for authorization of actions and attributes. It includes the ResourcePolicy::Policy module which provides the policy configuration via policy method. This method is used to define the authorization rules for each action and attribute.

The policy method defines the rules for creating, updating, and showing a post, as well as reading and writing the body and author_phone attributes. The authorization rules specify the conditions under which an action or attribute is allowed. For example, creating a post is only allowed if the current user is an editor and updating a post is only allowed if the current user is the author.

Here's the updated code for our API controller with attribute-level authorization using the resource_policy gem:

# app/controllers/api/v1/posts_controller.rb

class API::V1::PostsController < ApplicationController
  before_action :authorize_user!

  def create
    @post = Post.new(post_params)

    when_authorized(@post, :create) do |protected_post|
      @post.save!
      render json: serialized(protected_post)
    end      
  end

  def update
    @post = Post.find(params[:id])
    when_authorized(@post, :update) do |protected_post|
      @post.update!(post_params)
      render json: serialized(protected_post)
    end
  end

  def show
    @post = Post.find(params[:id])
    when_authorized(@post, :show) do |protected_post|
      render json: serialized(protected_post)
    end
  end

  private

  def when_authorized(post, action_name)
    policy = PostPolicy.new(post, current_user)

    if policy.action(action_name).allowed?
      return yield(policy.protected_resource)
    else
      render json: { error: 'not authorized' }, status: 403
    end
  end

  def serialize(post)
    # custom serialization logic
  end
end

Our updated controller does not have before_action :authorize_user! hook anymore, but handles all the authorization logic in when_authorized method.

The when_authorized method is used to wrap the logic in the action methods (create, update, and show). This method takes in two parameters: post and action_name.

The method starts by initializing a PostPolicy object with the post and current_user as parameters. The PostPolicy object at first will determine if the current user is allowed to perform the action specified by action_name on the post. Then it will return protected_resource object.

Protected resource

The protected_resource is a special ResourcePolicy object that returns nil for each unauthorized attribute, and returns the actual value otherwise. This makes it very handy for API calls where you need to return only authorized data.

For demonstration purposes, let's assume we have the two user roles: guest and admin. The following examples show the output of the show action for each of these roles.

Guest role:

{
  "id": 1,
  "body": "This is a sample post body",
  "author_phone": null
}

Admin role:

{
  "id": 1,
  "body": "This is a sample post body",
  "author_phone": "555-555-1234"
}

We have single source of truth. We can always update our PostPolicy configuration when we need to protect more attributes. No more code duplication or accidental data exposure. It wasn't an easy journey, bet we made it.

Final thoughts

Authorization is a complex topic and I tried really hard not to go to deep in to the details. That's why I only touched the very basics of resource_policy gem and how to use it to solve simple-enough authorization problems.

In conclusion, authorization in a Ruby on Rails API is an important aspect of ensuring the security and privacy of data and resources. Without authorization, anyone can access any resource or action in the API, which is unacceptable in most applications. Action-level authorization is a simple solution that can be implemented using the before_action method, but it is limited in its granularity. Attribute-level authorization provides a more flexible and robust solution, and can be achieved using the resource_policy gem. The resource_policy gem allows for the definition of policy classes that specify the authorization rules for actions and attributes, making it easier to manage authorization at different levels of granularity.

In this article, we have covered the basics of authorization in a Ruby on Rails API, and provided examples of how to implement action-level and attribute-level authorization. By understanding the concepts and methods discussed in this article, developers can implement effective authorization in their Ruby on Rails APIs, ensuring the security and privacy of their data and resources.

FormService: a PORO ServiceObjects with a state

Povilas Jurčys — Mon, 30 Jan 2023 15:44:40 +0000

The ServiceObject pattern is a powerful way to encapsulate specific business actions or workflows in Ruby on Rails. By separating concerns and keeping your controllers lean, ServiceObjects can help make your codebase more maintainable and easier to understand.

The example provided, CreateUser, is a simple ServiceObject that takes in user parameters, creates a new user, and sends a welcome email. The call method is the main entry point for the ServiceObject and should contain all the logic needed to perform the desired action.

Here's an example of the CreateUser service class:

class CreateUser
  def self.call(...)
    new(...).call
  end

  def initialize(user_params:)
    @user_params = user_params
  end

  def call
    user = User.create!(@user_params)
    UserMailer.welcome_email(user: user).deliver_now
    user
  end
end

To use this CreateUser service in your controller, you can call the call method on the class and pass in the necessary parameters.

class UsersController < ApplicationController
  def create
    user = CreateUser.call(user_params: params[:user])
    redirect_to user_path(user)
  end

  private

  def user_params
    params.require(:user).permit(:name, :email, :password)
  end
end

ServiceObjects and validation

When using the ServiceObject pattern in Ruby on Rails, it's important to consider how to handle validations. Validations are a crucial part of any application and are used to ensure that the data being passed to the ServiceObject is in the correct format and meets certain requirements.

This is where FormObjects shine!

In my Using FormObject pattern in Ruby APIs post I already talked what's so great about FormObjects. In short, the FormObject pattern is a way to encapsulate form logic and validation in a separate object. It can be used in conjunction with the ServiceObject pattern to separate validation and the actual action.

Here's an example of how you could use a FormObject and ServiceObject together in a controller:

class UsersController < ApplicationController
  def create
    form = CreateUserForm.new(user_params)
    if form.valid?
      user = CreateUser.call(form.user_params)
      redirect_to user_path(user)
    else
      render :new
    end
  end

  private

  def user_params
    params.require(:user).permit(:name, :email, :password)
  end
end

In this example, the controller creates a new instance of the CreateUserForm FormObject and passes in the user_params. The FormObject is responsible for validating the user_params and returning a boolean value indicating if the form is valid.

If the form is valid, the controller calls the CreateUser.call method and passing the form.service_params. This is the ServiceObject responsible for creating the user and sending a welcome email.

If the form is not valid, the controller will render the new template and display the errors from the FormObject.

Here is an example of how the CreateUserForm FormObject could look like:

class CreateUserForm
  include ActiveModel::Model

  attr_accessor :name, :email, :password

  validates :name, :email, :password, presence: true
  validates :email, format: { with: /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i }

  def service_params
    { name: name, email: email, password: password }
  end
end

In this example, the FormObject includes the ActiveModel::Model module, which provides basic form functionality, such as validation and attribute accessors. The FormObject defines the attributes name, email, password and uses Rails built-in validation methods validates to check for the presence and format of the attributes.

The service_params method returns a hash of the attributes that will be passed to the ServiceObject.

By using the FormObject and ServiceObject pattern, you can keep your controllers lean and focused on their main responsibility, which is to handle the flow of the application. The FormObject is responsible for validating the data and the ServiceObject is responsible for performing the actual action.

This approach helps to separate concerns, making your codebase more maintainable and easier to test.

FormService: one step further

When working with ServiceObjects in Ruby on Rails, it can be useful to have a way to track the state of the object, including whether or not the action was successful, the result of the action, and any errors that occurred. One way to achieve this is by using a FormService, which combines the functionality of a FormObject and a ServiceObject, and returns a state object that contains this information.

Here is how FormService might look like:

class FormService
  def initialize(form_instance, service_class)
    @form_instance = form_instance
    @service_class = service_class
  end

  def call
    FormService::State.new(
      form: @form, service_class: @service_class
    )
  end
end

This class is just a syntactic sugar which makes it look like a service. Real magic happens in FormService::State object. The FormService::State class is responsible for holding the state of the object and providing access to the result, success and errors after the FormService is called:

class FormService::State
  NO_ERRORS = ActiveModel::Errors.new(nil)

  def initialize(form:, service_class:)
    @form = form
    @service_class = service_class
  end

  def success?
    errors.empty?
  end

  def result
    return nil unless success?
    result!
  end

  def errors
    @errors ||= @form.invalid? ? @form.errors : NO_ERRORS
  end

  private

  def result!
    return @result if defined?(@result)
    @result = @service_class.call(@form.service_params)
  end
end

Here's an example of how you could use the FormService in a controller:

def create
  user_form = UserForm.new(user_params)
  outcome = FormService.new(user_form, CreateUser).call
  if outcome.success?
    redirect_to user_path(outcome.result)
  else
    @errors = outcome.errors.full_messages
    render :new
  end
end

In this example, the controller creates a new instance of the UserForm FormObject and passes in the user_params. The FormService is initialized with the UserForm form object instance and the CreateUser service class. The call method is called on the FormService and it returns a FormService::State object.

You can use the outcome object returned by the FormService to handle the flow of the application. In the example above, if the outcome is successful, the controller redirects the user to the appropriate page, otherwise, it renders the new template and displays the errors.

This approach allows you to separate validation and the actual action, making your codebase more maintainable, and your application more predictable. You can also make it more robust by handling different types of errors or adding more methods to the FormService::State class.

Final thoughts

One of the advantages of using the FormService is that it allows you to keep your ServiceObject stateless. A stateless object is an object that does not maintain any information about its previous interactions and can be reused without any side-effects. This can be beneficial in a number of ways and can help to avoid an extra layer of complexity in your application.

When using the ServiceObject pattern, it's common to pass in the data to be used for the action as an argument to the call method. The ServiceObject then performs the action using the data and returns the result. This approach can work well for simple actions, but as the complexity of the application increases, it can be challenging to manage the state of the ServiceObject.

By contrast, the FormService allows data validation and the action responsibilities to be separated. The FormObject is responsible for validating the data, and the ServiceObject is responsible for performing the action. The FormService then calls the call method on the ServiceObject, passing in the validated data.

Additionally, by keeping the ServiceObject stateless, you can easily reuse the ServiceObject for different use cases, and also you can use it in a variety of contexts without any changes.

DEV Community: Povilas Jurčys

A New Cop in Town: rubocop-rspec_parity

What it does (in plain human words)

Who this is for

Quick example

TL;DR

[Boost]

How I Ended Up Building With GitHub Copilot (the Remote One) And Why It Still Feels Kinda Wild

Povilas Jurčys ・ Nov 22

How I Ended Up Building With GitHub Copilot (the Remote One) And Why It Still Feels Kinda Wild

The Moment I Realized This Thing Was Unreal

How I Actually Use It (Honestly, Everywhere)

When Copilot Acts Like a Very Confident Intern

The UI? Mostly Copilot. Thank God.

Tests? Nope. I Don’t Trust It There.

Why Copilot Just Works Better For Me

To the Skeptics

Final Thoughts

How to use custom gems without changing the Gemfile

Intro

Gemfile.personal technique

1. Add the Gemfile.personal to the project's root directory

2. Install gems using the Gemfile.personal file

3. Globally ignore Gemfile.personal and Gemfile.personal.lock

Final Thoughts

FactoryBot: the secret weapon called @overrides

Intro

Problem with many-to-many dependencies

Using @overrides for two-way dependencies

Summary

You don't know RSpec: intro to RSpec for RSpec professionals

Intro

Do you know describe?

describe, context, and example_group

fdescribe and fcontext

xdescribe and xcontext

Do you know it?

Custom aliases for describe and it

Do you know let?

super() and describe

Do you know subject?

Unnamed subject VS let

Complexities of the named subject

Summary

Intro to GraphqlRails

Introduction

Not just extension for graphql-ruby

Getting hands dirty

Attaching graphql types to models

Testing

Decorators

Rendering errors

Final Thoughts

Many ways to write RSpec custom matchers

Introduction

Two Approaches

Creating matcher with alias_matcher

Creating matcher define_negated_matcher

Creating matcher with matcher

Describing the matcher Result

Customizing Description

Customizing Failure Messages

Custom Matchers with Arguments

Chaining custom matchers

Embracing Ruby Class Matchers: When and Why to Use Them

Creating a Ruby Class Matcher

Using the Ruby Class Matcher

Optimal Long-Term Solution

Conclusion

Deep Dive into RSpec's let Helper

Introduction

Understanding let Blocks in RSpec

Using super() within let blocks

Understanding the impact of super() in the subject

let! - the non-lazy alternative

When exactly are let! variables invoked?

Conclusion

Protect your GraphQL data with resource_policy

Two layers of protection

What is resource_policy?

1. Add the `Gemfile.personal` to the project's root directory

2. Install gems using the `Gemfile.personal` file

3. Globally ignore `Gemfile.personal` and `Gemfile.personal.lock`

Do you know `describe`?

`describe`, `context`, and `example_group`

`fdescribe` and `fcontext`

`xdescribe` and `xcontext`

Do you know `it`?

Custom aliases for `describe` and `it`

Do you know `let`?

`super()` and `describe`

Do you know `subject`?

Unnamed `subject` VS `let`

Complexities of the named `subject`

Creating matcher with `alias_matcher`

Creating matcher `define_negated_matcher`

Creating matcher with `matcher`

Understanding `let` Blocks in RSpec

Using `super()` within `let` blocks

Understanding the impact of `super()` in the `subject`

`let!` - the non-lazy alternative

When exactly are `let!` variables invoked?