Customize context inclusion with let_it_be or AnyFixture

[Systho]

With Rspec, there is an idiomatic way to customize context inclusion by providing a block : https://relishapp.com/rspec/rspec-core/docs/example-groups/shared-context#declare-a-shared-context,-include-it-with-%60include-context%60-and-extend-it-with-an-additional-block

This will allow to write thinks like

# with_an_invoice.rb
shared_context "with an invoice" do
  let(:invoice_owner){ raise "you must provide an invoice owner when including this context" }
end
....
# actual spec
include_context("with an user owning resources")# this context exposes a complex let(:user) 
include_context("with an invoice") do # this context exposes a complex let(:invoice)
  let(:invoice_owner){ user } # here I am using the previous user to customize the invoice
end

When following this pattern with let_it_be , the customization block is added to the list of before_all, it does not override the previous one.

How do you handle this scenario ?

[palkan]

Do I understand correctly: if you replace let with let_it_be in both places in the example above, it doesn’t work as expected and invoice_user != user?

So, you suggest to make it possible to override let_it_be within the same context?
Like this:

describe “smth” do
  let_it_be(:user) { create(:user, name: “A”) }
  let_it_be(:post) { create(:post, user: user) }
  
  let_it_be(:user) { create(:user, name: “B”) }

  specify do
    expect(user.name).to eq “B”
    expect(post.user).to eq user
    expect(User.where(name: “A”).any?).to eq false
  end
end

[Systho]

Yes, that is one way of doing it and I think it is the correct way because this would make let_it_be behave more similarly to let

I think it is ok if the user "A" exists though, it matches the semantic of let_it_be which is closer to let! than let.

The main usage for me would be using it include_context but it boils down to allow overriding let_it_be in a nested context I think.

describe “smth” do
  let_it_be(:user) { create(:user, name: “A”) }

  context "with a user named B" do
    let_it_be(:user) { create(:user, name: “B”) }
    let_it_be(:post) { create(:post, user: user) }
 
    specify do
      expect(user.name).to eq “B”
      expect(post.user).to eq user
      expect(User.where(name: “A”).any?).to eq true # user record exists but is not associated with post
    end
  end
end

Does it make sense ?

[palkan]

The example you provided should work, post should use the user "B".

The following won't work:

describe “smth” do
  let_it_be(:user) { create(:user, name: “A”) }
  let_it_be(:post) { create(:post, user: user) }

  context "with a user named B" do
    let_it_be(:user) { create(:user, name: “B”) }
 
    specify do
      expect(user.name).to eq “B”
      expect(post.user).to eq user
      expect(User.where(name: “A”).any?).to eq true # user record exists but is not associated with post
    end
  end
end

[Systho]

but it would work with regular let and let! right ?

the "problem" is that let_it_be block is added to a list of BeforeAll hooks, while let block overrides the previous definition (if any)

For the moment, you explanation allowed me to make my suite work by introducing new contexts but I think my previous way of using context was more like this (which doe snot work) :

describe “smth” do
    context "with a user named B" do
      # result of include_context("with a post"){  let_it_be(:author) { create(:user, name: “B”) } }
      let_it_be(:author) { create(:user, name: “A”) } # this is inside the context file
      let_it_be(:post) { create(:post, user: user) } # this is inside the context file
      let_it_be(:author) { create(:user, name: “B”) } # this is the customization block
 
    specify do
      expect(user.name).to eq “B”
      expect(post.author).to eq user
      expect(User.where(name: “A”).any?).to eq true # user record exists but is not associated with post
    end
  end
end

[palkan]

Overriding let_it_be definitions within the same context is something we can implement, I think.
Dealing with nested let_it_be is a bit more complicated (though not impossible).

Will think about it during the work on the next release.