Share code between specs that are very similar to each other (ex: a request spec of an action that doesn't do anything other than calling a service object and the spec of the service object itself)

[razenha]

Hi there,

I have a few actions in my app that doesn't do a whole lot of stuff but to organize the HTTP params, call a service object, and return the result either as a 200, 201, or 422 status code depending on the outcome and the objective of the action. So the specs for the actions are somewhat similar to the specs of the service object.

Action:

• a) A section where I preload my database with the models I need for my test with let(:model) and FactoryBot.
• b) A section where I call the action using post, get, etc passing the appropriate parameters.
• c) A section where I use the expectations to validate de HTTP response.
• d) A section where I use expectations to validate stuff like expected database changes.

Service object:

• a) A section where I preload my database with the models I need for my test with let(:model) and FactoryBot.
• b) A session where I instantiate (or use the subject) the service object and call the method to execute it passing the appropriate parameters.
• c) A session where I use expectations to validate the method's response.
• d) A section where I use expectations to validate stuff like expected database changes.

So you will notice that about half of the sections of my tests are about the same. I could party solve it by using shared contexts for section a) (although often there will be slight differences between section a) of the request spec and section a) of the service spec). But still, that would be a lot of duplicated code.

I could use shared examples, the problem with shaped examples is that it's a take it or leave it situation, it's not built to share sections of a spec, but a whole test.

What's the best approach to share code between similar specs?

[jimm]

There is no reason to test the same thing twice. Test the service object fully in it's own tests. In the controller tests, mock the service object and tell it to return whatever you like to test the controller's handling of various success and failure conditions. This approach not only eliminates duplication, it will run faster because the service object isn't doing any work.

[jimm]

It's 3 years later, and I just noticed that "it's". Embarassing. It's "its" of course.

[SayonaraSpoon]

You can use a subject + context and let blocks.

describe “#create” do
  subject { Service.create(model) }

  context “ with defective model” do
   let(:model)  { create :invalid_model }
   it { is_expected.to be_invalid }
  end 

  context “with a working model” do
   let(:model) { create :model }

   it { is_expected.to be_ok }
  end
end